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CHAPTER  1 
INTRODUCTION 

The  Rome  Air  Development  Center  (RADQ  is  a  large  Air  Frace  laboratcxy  that 
does  exploratory  develc^ment  of  Air  Force  command,  control,  communicatitxis,  and 
intelligence  (C3I)  systems.  In  1987,  RADC  developed  a  knowledge-based  aircrew 
scheduler  to  meet  the  needs  of  single-seat  aircraft  unit  craitinuation  training.  (See 
APPENDIX  A  for  a  system  description.)  Unfortunately,  the  1987  prototype  was 
developed  in  a  LISP  environment  under  a  ccmimercial  expert  system  shell  called 
Knowledge  Engineering  Environment  (KEE).  The  cost  of  the  required  LISP  machine  and 
KEE  prohibited  direct  installation  of  the  prototype  in  q)erati(mal  units.  Furthermore,  the 
complexity  of  the  code  conqmsing  the  1987  prototype  made  modification  an  unpleasant 
prospect  Because  each  operational  unit  schedules  a  Uttle  differently,  the  ability  to  modify 
the  scheduling  system  is  an  important  consideration.  In  addition,  the  Air  Force  faces  many 
different  types  of  scheduling  problems  other  than  single-seat  aircrew  scheduling.  Some 
examples  of  these  other  problems  are  scheduling  of  operational  missions,  multi-person 
aircrews,  air  refueling,  and  aircraft  maintenance.  It  would  be  nice  if  there  were  some 
simple  programming  methodolo^  for  developing  software  solutions  for  these  problems  as 
well.  During  1989  and  1990,  the  1987  KEE  aircrew  scheduler  was  poned  to  the  Apple 
Macintosh  running  in  Microsoft  Excel.  (See  (CHAPTERS  4  and  5  and  the  APPENDIX). 

In  the  process,  a  new  metiiodology  for  programming  generic  scheduling  systems  was 
developed.  This  thesis  describes  the  new  aircrew  scheduling  prototype  and  the 
methodology  used  in  die  context  oi  other  relevant  research. 

The  following  chapter  describes  the  specific  scheduling  problem  which  must  be  solved  by 
Tactical  Air  (Command  (TAQ  units  flying  ringle-seat  aircraft  to  complete  required 
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ccmtinuation  training.  Requirements  and  constraints  fix’  A- 10  continuation  training  are 
described.  Flying  units  are  described  organizationally  because  responsibilities  and 
information  pathways  are  important  to  the  problem  solution.  The  manual  process  for 
scheduling  is  described  along  with  the  current  database  support  tool  The  goals  of 
scheduling  are  identified  and  an  automated  infonnation  system  for  scheduling  is  {xoposed. 

The  third  chapter  discusses  current  technology  tyrplicable  to  scheduling  and 
programming  in  general.  A  scheduling  system  typically  involves  a  moderate  amount  of 
data,  so  database  technology  is  addressed.  Specifically  covered  are  shortcomings  of 
tradidonal  database  models  and  efforts  to  bridge  them  Scheduling  algorithms  from 
operations  research  and  artificial  intelligaice  are  discussed.  Different  progranmiing 
languages,  environments,  and  methodotogies  are  described  for  iixplementing  an  aircrew 
scheduler.  Visual  programming,  a  new  mediodology  based  on  the  computers  increasing 
ability  to  handle  graphics,  is  presented  as  a  new  way  to  reduce  the  complexity  of  programs 
and  programming. 

In  CHAPTER  4,  a  visual  programming  methodology  based  on  Microsoft  Excel  is 
introduced.  Using  visually  explicit  data  structures  and  aninuted  programs,  the 
representational  complexity  ci  programs  is  reduced,  making  development  and  (tebugging 
simpler.  Software  engineering  concerns  which  arise  from  representational  complexity  such 
as  modifiability  and  verification  and  validation  ate  treated.  A  visual  programming 
methoddogy  also  helps  make  the  code  easier  to  change  and  believe  in.  The  grE^rhical 
programming  possible  in  Excel  is  described.  The  use  of  odier  attributes  inherent  in  Excel 
arxi  the  Macintosh  are  discussed.  The  high-level  database  functionality  of  Excel  is  credited 
widi  simplifying  scheduler  applications.  Windowing,  pull  down  menus,  and  mouse  input 
are  also  given  their  due. 
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CHAPTER  5  is  a  system  description  of  the  new  Excel  aircrew  scheduler  prototype. 
Data  structures  and  data  representation  are  described  in  detail.  The  algorithms  and  their 
operation  are  discussed.  User  functionality  is  described.  Shortcomings  of  the  current 
prototype  are  identified. 

In  CHAPTER  6,  the  use  of  Excel  for  other  applications  is  discussed.  There  are  a 
number  of  difEculties  associated  with  the  use  of  Excel  which  could  be  reduced  if  suggested 
improvements  were  implemented.  The  way  data  is  referenced  in  Excel  should  be  modified 
to  reduce  inconsistencies.  Excel's  macro  programming  was  designed  to  provide  analysis 
functionality,  not  as  a  complete  programming  language.  The  macro  language  needs  to  be 
formalized  or  a  complete  language  like  LISP  or  Pascal  should  replace  it  Finally,  Excel 
would  serve  better  with  additional  means  for  data  abstraction,  including  the  ability  to 
support  the  objea-oriented  paradigm  of  programming. 

CHAPTER  7  summarizes  the  thesis  and  indicates  the  direction  of  on-going  and 


planned  research. 
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CHAPTER  2 

PROBLEM  DESCRIPTION 

To  fulfill  its  mission,  the  Air  F(xt:e  requires  highly  trained  pilots.  After 
undergraduate  pilot  training  in  a  pardcular  aircraft,  pilots  move  to  their  assigned  squadron 
and  enter  into  continuation  training  which  continues  throughout  their  flying  career. 
Continuation  training  is  designed  to  make  pilots  combat  capable  and  to  keep  them  that  way 
by  frequendy  retesting  critical  skills.  In  addition,  continuation  training  is  used  to  upgrade 
pilot  qualification,  a  certification  of  enharced  ability  and  greater  experience.  Flying  skills 
are  supplemented  by  a  variety  of  ground  training  classes.  Ground  training  includes 
simulator  time,  bail-out  {xactice,  and  survival  training. 

Films  have  additional  duties  (duties  not  including  flying;  DNIF)  which  impact  their 
availability  for  training.  Staff  jobs,  such  as  Squadron  Scheduling  Officer  or  Training 
Officer,  can  detract  signfficandy  from  training  oiqx)rtunities.  Sickness,  medical  and  dental 
appointments,  and  immunizations  often  require  pilots  to  be  suspended  from  flying  for 
physiological  reasons.  Daily  tasking  assignments  like  Squadron  Safety  Officer  also 
preclude  flying.  Currency  in  all  ground  training  events  is  a  prerequisite  for  flying  and  can 
limit  the  pool  of  pilots  available  to  fly.  For  safety,  pilots  are  not  allowed  to  fly  Itxiger  than 
12  hours  Gcngth  of  flying  day  concept).  Furthermore,  pilots  must  be  given  12  hours  of 
crew  rest  after  flying  before  they  fly  agaixL 

The  rules  governing  pertinent  aspects  of  flying  and  flight  training  are  spelled  out  in 
detail  in  specific  Air  Force  regulations.  A- 10  flight  training  requirements  are  listed  in 
Tactical  Air  (Command  Regulation  TACR  51-50  Volume  n.  The  hard  constraints  imposed 
by  TACR  51-50  make  aircrew  scheduling  for  A-10  continuation  training  a  very  difficult 
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process.  For  example,  there  ate  17  different  training  events  required  and  each  of  them 
must  be  completed  a  certain  number  of  times  by  each  pilot  during  the  six-month  training 
term.  Each  event  has  an  associated  currency  period  which  reflects  the  frequency  of 
training.  For  example,  for  the  landing  event,  the  currency  is  thirty  days.  If  a  pilot  fails  to 
land  fOT  thirty  days,  that  pilot  is  out  of  currency  for  landing  and  must  fly  with  an  instructor 
pilot  to  regain  landing  currency.  "Instructor  pilot"  is  a  qualification  rating  which  may  be 
achieved  through  the  upgrade  process.  A- 10  pilots  have  one  of  five  different  qualifications: 
mission  qualification  training  (an  initial  qualification  given  after  completion  of 
undergraduate  pilot  training),  mission  qualified,  two-ship  flight  leader,  four-ship  flight 
leader,  and  instructor  pilot  To  upgrade,  a  pilot  must  complete  a  certain  number  of  different 
training  events  satisfactorily  and  must  normally  fly  with  an  instructor  pilot  for  evaluation 
purposes.  In  continuation  traiiung,  "flying  with  an  instructor  pilot"  implies  that  an 
instructor  pilot  flies  in  a  sq)arate  aircraft  but  observes  performance  and  issues  instructions 
and  c<»rections  orders  as  needed. 

In  addition  to  the  hard  constraints  listed  above,  there  are  a  number  of  soft  • 
constraijits  (preferences)  which  vary  with  the  situation  and  can  malce  scheduling  objectives 
nebulous.  Pilots  have  preferences  about  when  they  take  leave,  who  they  fly  with,  and 
when  they  perform  uaining  and  other  duties.  Pilots  often  negotiate  with  the  scheduling 
officer  to  attain  these  goals.  Squadron  supervisors  also  have  special  desires,  such  as  the 
desire  to  improve  a  particular  pilot's  qualification.  However,  supervisors  usually  dictate 
their  needs  to  the  scheduling  (rfiker,  rather  than  negotiate  with  theno.  The  primary  goal  of 
the  scheduling  officer  is  to  attain  resources  necessary  to  give  all  pilots  ample  training 
oppcMtunities,  build  partial  schedules  using  these  resources,  and  fill  all  partial  schedules 
with  the  most  appropriate  pilots.  ^  Because  of  the  differing  goals  of  different  elements  in 

^Scheduling  tasks  are  done  in  the  order  implied  by  the  last  sentence;  relative  difficulty  of  tasks  increases 
also  in  the  order  implied. 
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the  organization,  it  is  very  difficult  to  airive  at  a  metric  of  schedule  goodness  that  is 
acceptable  to  all. 

Operational  Air  Force  units  take  flight  training  very  seriously  because  of  its  inq)aa 
on  combat  capability  and  aircrew  safety.  It  is  a  primary  measure  of  unit  missicxi 
effectiveness  and  reflects  directly  on  the  leadership  of  the  commander.  Therefore, 
commanders  normally  structure  their  organizadon  to  achieve  required  training  and  improve 
the  overall  ability  of  their  pilots.  Operadonal  A- 10  units  (wings)  are  often  subdivided  into 
squadrons.  Training  officers  report  training  progress  to  supervisors  at  each  level  and  use 
scheduling  officers  on  staff  to  ensure  that  all  pilots  receive  sufficient  sorties  to  ccHnplete 
training.  Training  officers,  scheduling  officers,  and  others  are  normally  flying  pilots  who 
must  also  coiiq)letB  continuation  trairung.  'Diat  is,  their  staff  functions  are  additional  duties 
assigned  which  generally  do  not  preempt  the  primary  job  of  flying.  Because  pilots  can  ill- 
afford  additional  work,  automatitxi  of  the  scheduling  process  is  highly  desirable. 

The  problem  of  scheduling  aircrews  to  single  seat  aircraft  continuation  training  is 
similar  to  the  classical  qxrations  research  problem  of  choosing  the  best  way  to  allocate 
resources  to  coizqwting  activities  amidst  constraints.  Using  this  view,  each  pilot  represents 
an  activity,  or  job,  which  requires  resources  to  complete.  Resources  include  aircraft, 
munitions,  gunnery  ranges,  and  instructor  pilots.  (Note;  instructor  pilots  are  both 
activities  and  resources). 

In  current  practice,  the  resources  (except  instructor  pilots)  are  typically  allocated 
based  on  availability  and  compiled  in  the  form  of  a  partial  schedule  based  on  the  training 
needs  of  the  squadron.  (See  Figure  1.)  After  a  partial  schedule  has  been  developed,  with 
aircraft,  configurations,  and  ranges  filled  in,  it  is  completed  by  assigning  pilots  to  each 
smtie.  This  two-step  process  is  used  to  reduce  scheduling  complexity  and  allow  the 
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Figure  1.  A  Partial  Daily  Schedule  for  A- 10  Continuation  Training 

scheduling  officer  to  use  knowledge  available  at  the  time.  For  exan^le,  resources  must 
typically  be  reserved  before  pilots  have  to  be  placed  on  the  schedule.  Squadrons  which 
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must  negotiate  with  each  other  and  support  organizadons  for  aircraft,  munitions  and  other 
external  stores,  and  weapons  ranges  about  a  month  before  they  will  be  used.  The 
scheduling  officer  normally  has  only  general  knowledge  about  training  needs  that  far  in 
advance.  On  the  other  hand,  pilots  must  be  scheduled  to  fly  only  one  week  in  advance. 

The  scheduling  officer  therefore  can  make  a  partial  schedule  consisting  of  scvties  first,  then 
con^lete  the  schedule  at  a  later  time  by  assigning  pilots  who  need  the  scheduled  trairung 
missions  the  most .  Events  often  preclude  a  pilot  from  flying  (i.e.,  assignment  to  an 
exercise)  or  increase  a  pilots  requirements  ftv  a  mission  (i.e.,  failure  to  accomplish  a 
previous  training  event  satisfactcvily),  so  it  is  effective  to  schedule  in  this  manner. 

Scheduling  is  a  dynamic  process.  Once  a  schedule  has  been  oxnpleted,  it  must  be 

changed  if  any  assumption  used  to  make  it  is  invalidated.  Aircraft  may  fail  or  weather  may 

preempt  a  planned  mission  set  Pilots  become  ill,  require  emergency  leave,  or  fail  to 

complete  a  previous  event  requirement  The  squadron  supervisor  may  re-<xder  preferences 

in  light  or  in  lieu  of  changes.  These  types  of  changes  force  the  scheduling  officer  to 

modify  the  schedule  from  four  to  eight  times  before  flying  it^  However,  schedule 

consistency  is  also  desirable  because  pilots  must  have  time  to  plan  for  missions. 

Therefne,  the  scheduling  officer  often  posts  a  suboptimal  schedule  with  a  few  changes, 

% 

radier  than  a  completely  reoideted,  optinoal  schedule. 

To  add  to  the  complexity,  day-to-day  scheduling  is  only  the  default  case. 
Opendonal  units  frequently  deploy  to  joint  or  service  exercises  far  from  their  assigned 
base.  Also,  q)ecialmisaons  are  occasionally  required  to  demonstrate  unit  c^mbility  in 
non-standard  tasks,  aid  in  recruiting,  or  perform  a  ceremonial  or  public  relations  flight 
The  scheduling  officer  must  arrange  for  pilots  and  flight  resources  for  tiiese  events  as  well 


^Data  bom  one  squadron. 
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as  for  ncnnal  Gocal)  training.  These  additional  activities  often  require  coordination 
betweeit  units  for  needed  support  such  as  airfield  support,  air  refueling,  etc.  The  primary 
cnmmuucation  medium  between  units  is  the  telephone,  implying  that  requests  may  be 
missed  and  suppon  may  fail  to  materialize  when  needed.^ 

Pertinait  pilot  data  are  currently  tracked  in  a  database  (AFORMS)  managed  by  die 
centralized  computing  facility  on  each  Air  Force  base.  The  AFORMS  database  tracks  pilot 
event  completions,  currencies,  and  qualifications  and  generates  reports  of  the  data  which 
are  distributed  weekly.  Squadrons  update  the  database  using  optically-scanned  forms  or  an 
Interactive  input  routine  through  a  terminal. 

From  a  squadron  scheduler’s  viewpoint,  the  AFORMS  database  is  not  adequate 
because  it  does  not  store  all  die  data,  ouputs  the  data  infirequendy  and  inflexibly,  and  is 
difficult  to  get  die  data  into.  AFORMS  does  not  track  all  required  data,  such  as  availability, 
staff  assignments,  and  event  completion  in  preparation  for  qualification  or  rating  change. 
Therefore,  the  scheduling  officer  must  remember  or  record  this  additional  data  using  pencil 
and  ptper  or  grease  board.  The  AFORMS  data  is  not  readily  available  in  real-time. 
Therefore,  schedule  iiputs  and,  ultimately,  schedules  are  based  on  old  data.  In  addition, 
when  die  AFORMS  data  is  delivered,  it  is  in  die  form  of  a  ’’core  dump"  resulting  in  a  20-50 
page  printout  Some  reports  in  the  printout  are  useful  for  determining  priority  pilots  for 
different  events,  but  user  requested  reports  are  not  possible.  Nonstandard  reports  would 
probatdy  be  of  questioiiable  value  anyway,  given  the  time  frame  of  data  delivery,  but  real¬ 
time  manipulation  of  the  data  would  be  valuable  in  determining  who  should  be  sdieduled  or 
which  pilots  can  feasibly  be  flown  in  a  particular  slot  Scheduling  officers  usually  present 
data  to  squadron  or  unit  supervisors  (e.g.,  dw  Wing  Director  of  Operations  (DO)  at  standim 

^Strategic  Air  Command  now  uses  a  system  called  MASMS  to  automate  reservations  for  loW' jevel  tracks 
for  B-52  training. 
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briefinp.  Slides  used  in  these  briefinp  contain  data  from  AFORMS  and  could  % 
conceivably  be  generated  automatically,  but  the  AFORMS  is  too  inflexible  to  supprat  this 
function  currently.  AFORMS  cannot  present  data  graphically,  a  functitn  which  would  aid 
analysis  of  training  stams  and  point  out  the  need  for  resources  of  different  types.  In' 
addition,  if  automated  scheduling  were  integrated  with  the  database,  schedules  could  be 
generated  and  printed  automatically,  rather  titan  being  generated  by  hand  iiom  hard  ct^y 
data  and  then  typed  by  a  stenographer.  Bnally,  AFORMS  has  no  intelligence  ot 
Mendliness  with  regard  to  terminal  data  entry.  The  data  input  routine  remembers  nothing, 
cannot  suggest  inputs,  and  lacks  even  menus  or  mouse  support.  Instead,  each  piece  of  data 
must  be  painstakingly  typed  in  by  hand. 

Qeaiiy,  the  current  level  of  automation  (AFORMS  database)  does  not  meet  the 
scheduling  needs  of  operational  flying  units.  Neariy  all  scheduling  officers  use  a  grease 
board  or  pencil  and  paper  to  record  additional  data  and  current  scheduling  status,  despite 
the  availability  of  automation  equipment.  The  reasons  for  depending  on  the  grease  board 
include  a  distrust  of  automation,  the  lack  of  powerful  automated  tools  for  data  handling  and 
analysis,  and  significantly,  the  need  fcH*  data  visibility  between  pilots,  scheduling  officers, 
and  supervistxs. 

Scheduling  officers  have  different  metiiods  of  generating  schedules  using  the  data 
available  to  thettL  Although  some  scheduling  officers  have  formal  training  in  operations 
research,  nearly  all  use  heuristics  and  "comnoon  sense"  to  develop  satisficing^  schedules. 
Hurrum  schedulers  are  able  to  detomine  relatively  good  heuristics  and  apply  titem,  so  long 
as  they  have  the  data  and  tiie  patience  to  maiupulate  it  to  fit  tiie  preconditions  on  tiie 
heuristics.  Unfntunately,  human  memory  is  vdatile  and  human  patience  has  its  limits.  In 


^near  optimal;  satisfying 
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practice,  human  schedulers  using  heuristics  constantly  find  themselves  asking  for 
manipulations  to  determine  an  appropriate  pilot,  for  example,  "Who  is  at  least  a  two-ship 
flight  lead,  current  in  night  air-to-air  refueling,  has  not  flown  since  3  AM.  on  Tuesday  and 
needs  a  night  landing  the  most?"  In  addition,  its  easy  for  human  schedulers  to  forget  one 
or  more  hard  or  soft  constraints  during  the  scheduling  process,  resulting  in  an  int^jpropriate 
or  disgrunded  pilot  There  are  few  scheduling  officers  who  have  not  generated  a  very  bad 
schedule,  despite  knowing  reasonable  scheduling  heurisdcs. 

As  mentioned  above,  schedule  optimality  is  desired,  but  "optimal"  means  different 
things  to  different  people.  Fortunately,  ample  training  resources  generally  exist  for 
completing  minimum  acceptable  training  requirements.  Ordinarily,  in  day-to-day 
operations,  it  is  nxire  in^xntant  to  arrive  at  a  schedule  which  satisfies  requirements,  rather 
than  one  that  is  optimal  (in  whatever  sotse).  In  context  of  a  Itmger  time  frame,  unit 
commanders  strive  to  maximize  training,  but  also  emphasize  a  host  of  other  pet^le-  and 
mission-txiented  performance  metrics.  Training  can  be  measured  in  terms  of  the 
percentage  of  combat  capable  pilots,  number  of  upgrades,  and  currency  delinquency  rates. 
Commanders  protect  their  people  and  therefore  give  attention  to  tilings  like  safety  and 
workload  distribution.  Commanders  are  tasked  with  enhancing  unit  performance  which  is 
measured  m'terms  of  rapid  generation  capability,  weapons  delivery  and  simulated  air 
combat  scores,  and  other  competence  and  effectiveness  metrics.  In  short,  schedule 
optimization  is  the  global  goal,  but  the  objective  function  for  aircrew  scheduling  is  a  very 
conqilicated  equation. 

Given  tiie  nature  of  the  aircrew  scheduling  task  and  the  level  of  automation 
available,  the  sdieduling  officer  does  an  admirable  job  oi  producing  aircrew  schedules. 
However,  the  current  prcx;ess  used  is  time-consuming,  tedious,  and  error-prone,  despite 
the  professional  dedication  of  the  scheduling  offico*.  Current  technology  exists  which 
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could  improve  the  scheduling  process  dramatically.  It  consists  of  an  integrated  infmnation 
system  based  on  a  set  of  automated  tools  which  flexibly  transfers  and  presents  data  in  real¬ 
time  and  assists  in  the  schedule  generation.  Automatic  scheduling  is  included  in  the  tool  set 
by  employing  heuristics  (or  another  type  of  solution  method)  to  generate  "good"  schedules 
which  do  not  violate  constraints.  The  tool  set  adapts  to  changes  inherent  in  the  domain  and 
still  generates  robust,  rather  constant  schedules.  The  tool  set  supptnis  resource  and 
training  analysis  for  additional  decision  making.  The  infcxmation  system  is  designed  to 
allow  for  rapid,  lossless  data  flow  between  unit  supervisors,  local  and  distant  support 
elements,  and  the  scheduling  officer,  if  not  the  pilots  as  well.  That  the  information  system 
described  is  possible  with  current  technology  is  proved  by  the  existence  of  one  example: 
the  system  described  in  CHAPTER  5. 
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CHAPTER  3 

COMPUTER  TOOLS  AND  METHODOLOGIES  FOR 
AUTOMATIC  AIRCREW  SCHEDULING 

Simply  put,  creating  an  effective  sch^ule  depends  on  having  some  generic  method 
of  scheduling  and  applying  the  method  to  some  specific  data  set  which  adequately  describes 
the  worid.^  Because  data  is  the  more  fundamental  problem  for  current  tactical  aircrew 
scheduling,  database  technology  will  be  discussed  first  and  scheduling  procedures  will 
follow.  Then,  because  a  program  must  be  written  to  automate  the  scheduling  process, 
programming  methodologies  will  be  considered. 

Database  Technology 

Most  problems  which  are  interesting  or  useful  to  solve  using  a  computer  have  large 
data  sets  associated  with  them.  Database  management  systems  (DBMS)  are  used  to  store 
and  manipulate  data  efficiently,  but  the  different  views  oi  the  data  required  by  different 
users  has  made  it  desirable  to  ioqnove  upon  current  database  models.  The  AFORMS 
database  management  system  is  representative  of  eariy  militaty  database  technology. 
AFORMS  and  the  centralized  data  processing  model  on  which  it  is  implemented 
unnecessarily  restria  the  flow  of  infnmation  required  to  schedule  pilots  effectively. 

Qirrent  DBMS  products  are  friendlier  than  AFORMS,  but  nuuiy  still  lack  needed 
functions.  DBMS  shortoomings  are  being  addressed  by  research,  primarily  research  aimed 
at  folding  in  lessons  learned  fiom  other  fields  to  integrate  richer  rqnesentational  schemes 

^In  fact,  p^lem  solving  in  general  depends  on  having  some  solution  method  and  using  it  on  current  world 
data.  Typically,  military  planning  suffers  not  from  lack  of  a  solution  method,  but  from  a  lack  of  dau  or  an 
easy  means  to  elicit  dam  from  clogged,  unfriendly  command  and  control  systems.  This  is  especiaUy  true 
whm  a  crisis  vises. 
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and  add  general  progranuning  features.[39]  Several  attempts  have  been  made  along  these 
lines,  but  data  modeling  is  sdll  a  research  issue.  Finally,  database  systems  based  on  a 
distributed  processing  model  and  implemented  across  a  wide-bandwidth  netwcxlc  facilitates 
data  dissemination  better  than  the  centralized  data  processing  does. 

Classical  (iiiachine^)riented).  Data  Models.  There  are  a  number  of  different  data 
nxxlels  used  by  current  database  management  systems.  Most  DBMS  products  are  based  on 
one  of  the  classical  models:  hierarchical,  network,  or  relational.  Data  is  organized  as  a 
forest  of  trees  in  the  hierarchical  model  and  as  a  directed  gn^h  in  the  network  model.  Both 
the  hierarchical  and  network  schemes  have  difficulty  representing  many-to-many 
relationships  and  tend  to  require  procedurally-rxiented  operations  based  (xi  a  knowledge  of 
the  data  structures  involved.  In  contrast,  the  relational  model  is  mathematically  simple. 
Data  elements  are  stcxed  as  tuples  in  tables.  Queries  may  be  expressed  in  a  declarative 
fashion,  freeing  the  user  tiom  having  to  think  about  the  underlying  procedures  which 
actually  deliver  the  answer.  As  a  result,  users  prefer  relational  DBMS  over  systems  based 
on  one  of  the  other  two  traditional  models,  and  the  comnoercial  software  industry  has 
rapidly  responded  with  an  increasing  number  of  relational  DBMS  products.  [3] 

DBMS  Queries.  The  relational  model  suppmts  declarative  queries  to  some  extent, 
making  possible  a  simple  query  language  based  on  a  description  of  the  desired  data  set, 
rather  than  a  procedure  for  getting  it  However,  the  user  must  still  know  which  data  is  in 
which  table  and  specify  diat  information  in  die  query.  In  addition,  althou^  the  usa  may 
get  at  any  data  view  using  the  three  available  operations  (join,  select  project)  on  the  global 
database,  there  are  two  problems  which  can  arise  from  this  flexibility.  First  query  results 
can  be  incotrect  unless  the  schema  are  carefully  designed.  Second,  it  would  be  nice  to  be 
able  to  update  the  data  base  when  viewing  it  from  any  angle.  However,  it  is  not  always 
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easy  to  input  infonnation  into  the  database  fiom  a  given  virtual  database  relation  because 
ambiguity  may  result.[3] 

Do  any  of  the  classical  DBMS  models  satisfy  current  user’s  requirements?  For 
many  q^Ucadons  (including  a  portion  of  the  aircrew  scheduler  prototype),  the  relational 
model  is  sufficient  However,  classical  models  are  based  on  the  need  for  efficient  machine- 
implementations  of  databases,  not  on  user’s  needs.  Most  DBMS  models  only  have  two 
levels:  the  schema  and  the  data.  Inheritance  of  infcmnation  inherent  in  a  taxoiomy  of 
objects  is  impossible  to  capture  using  two-level  models.  Also,  classical  models  often  blur 
the  distinction  between  a  set  of  data  and  a  type  of  data.  Different  perspectives  are  possible, 
but  difficult  to  separate.  The  problem  of  updating  virtual  relaticms  cannot  be  addressed 
using  a  purely  relational  approach.  Finally,  no  classical  model  supports  temporal 
modeling,  the  changes  in  data  over  time. 

Other  Models.  Semantic  data  models  have  been  developed  to  address  the  shortcomings 
of  classical  i4)proaches.  Semantic  data  models  like  the  entity-relationship  nxxiei  (Qien) 
focus  on  capturing  the  meaning  of  data,  rather  titan  on  being  machine-implementable. 

Other  exanqtles  of  semantic  models  are  tiie  Relational  Model/Tasmania  (Codd),  Semantic 
Data  Model  (McLeod  and  Hammer),  and  tiie  Event  Data  Model  (King  and  McLeod).  All 
semantic  data  models  improve  on  the  richness  of  data  representation  over  classical  models. 
They  differ  primarily  in  the  types  of  relationship  between  data  which  may  be 
expressed.[42] 

Object*oriaited  Databases.  Recently,  some  researchers  have  investigated  the  use  of 
an  object-oriented  approach  to  database  modeling.  Object-oriented  programming  is  a 
methodology  which  focuses  on  active  data  elements  rather  than  procedures  and  passive 
data.  The  data  elements  (objects)  are  encapsulated  and  modular  because  they  communicate 
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with  one  another  only  by  message-passing.  If  the  state  of  an  object  must  be  changed, 
typically  another  object  passes  it  a  message  requesting  the  change  and  the  procedures 
bound  to  the  requested  object  make  the  necessary  change.  Therefore,  each  object  knows 
how  to  alter  its  own  state  and  react  to  incoming  messages.[3, 4, 42] 

The  objea-oriented  data  model  also  allows  the  programmer  to  take  advantage  of  a 
class  hierarchy  and  use  the  inheritance  property  to  reduce  storage  requirements.  A  class  is 
defined  with  known  attributes,  default  values,  and  encapsulated  procedures.  An  object 
which  is  a  particular  member  of  a  class  becomes  only  an  instantiation  of  the  class.  If 
subclasses  exist,  they  may  inherit  data  and  procedures  from  their  superclass.  For  example, 
a  programmer  might  wish  to  represent  a  class  transport-asset  with  subclasses  truck,  cargo- 
plane,  and  ship.  Attributes  of  transport-asset  might  be  range,  speed,  location,  and 
capacity.  Transport-asset  would  also  have  an  associated  set  of  procedures,  for  example,  a 
procedure  for  changing  location.  Truck  and  sh^  would,  as  subclasses,  inherit  all  three  of 
those  attributes,  but  trucks  might  also  have  a  clearance  attribute  and  ships  might  have  a 
loading-resource  attribute.  Ship  might  have  additional  subclasses  like  tanker,  frigate,  and 
fast-cargo.  An  instance  of  the  class  fast-cargo  might  be  the  USS  Atlas  widi  loading- 
resource  for  the  instance  having  a  value  se^-loading-crane.  By  inheritance,  the  data  object 
USS  Atlas  would  also  have  data  slots  fen*  range,  speed,  location,  and  capacity,  as  well  as 
all  default  values  and  procedures  known  to  all  supetclasses.[33, 40] 

Using  the  object-oriented  paradigm,  database  researchers  can  easily  model 
generalization  and  aggregation  relationships  (is-a  and  a-part-of  relationships).  Qass 
information  is  easily  captured  and  manipulated  using  the  inheritance  property.  In  addition, 
objects  can  be  easier  to  manipulate  when  a  collection  is  presented  in  a  non-standard  view. 
Several  object-oriented  DBMSs  have  been  in^lemented;  there  is  increasing  support  for 
graphical  manipulation  ci  data  from  an  analytic  view.  Furtiiermore,  complicated  real-woiid 
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objects  are  more  easily  modeled  and  data  modularity  is  enhanced.  ThereftHe,  the  object- 
oriented  data  model  addresses  some  of  the  difficulties  associated  with  classical  models. 
The  primary  disadvantage  of  the  object-<»iented  nnodel  is  that  the  mathematical  simplicity 
and  declaradve  beauty  of  the  reladonal  model  are  forsaken  for  a  highly  procedural, 
somewhat  constricted  message  passing  scheme.^  [3, 4, 42] 

Lessons  from  Artificial  Intelligence  Research.  Knowledge  representation  has 
long  been  a  research  topic  in  the  field  of  artificial  intelligence  (AI).  Object-oriented 
programming  (frames/slots)  is  one  representation  method  used  widely  for  AI  applications. 
Other  representations  include  predicate  calculus,  production  rules,  semantic  networks,  and 
expectation  schema.  Data  manipulated  by  AI  systems  are  less  structured  and  less  certain 
than  data  associated  with  most  conventional  databases.  Therefore,  knowledge  and  data 
representation  schemes  in  AI  tend  to  be  more  flexible  and  less  pleasing  in  a  mathematical 
sense.  Moreover,  there  are  a  variety  of  ways  of  expressing  uncertainty  in  databases  due  in 
large  pan  to  AI  research.  Temporal  aspects  of  data  have  been  treated  by  a  number  of  AI 
systems.  The  biggest  drawbacks  from  the  rich  expressive  power  of  databases  based  on  AI 
knowledge  representation  are  that  they  are  generally  complex  and  large  databases  are 
difiBcult  to  manage  and  maintain.[31 

Database  Interface.  From  a  user's  standpoint,  a  DBMS  can  be  painful  to  use.  Oddly, 
the  typical  DBMS  restricts  input  and  output  It  requires  data  in  a  certain  way  and  is  not 
extroverted  about  "showing  what  it  knows."  Normally,  a  user  must  learn  a  command 
language  to  do  sorts,  attain  virtual  views,  edit  data,  or  even  to  get  raw  data  regui^tated 
from  an  existing  database  table.  Generating  a  non-standard  report  is  beyond  the  capability 
of  most  casual  users.  The  man-machine  interface  becomes  crucial  to  the  utility  of  die 


^or  more  infonnttion  r^anling  object-orienied  progfamming,  see  APPENDIX  C. 
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DBMS,  and  most  commercial  DBMS  products  are  incraporating  features  such  as  menus, 
windows,  and  mouse  input  to  make  the  user's  tasks  easier. 

Database  Access.  Data  must  be  accessible  to  those  who  need  it  The  current  AFORMS 
database  is  a  good  example  oi  how  a  constricted  data  flow  can  hinder  decision  making. 

The  centralized  data  processing  approach  that  AFORMS  epitomizes  separates  the  data  from 
the  user  both  in  terms  of  the  flexibility  of  data  manipulation  possible  and  response  time  of 
data  access  and  update.  Rather  than  giving  the  user  terminal  access  to  an  inflexible  DBMS, 
it  is  wiser  to  distribute  the  data  and  the  ability  to  manipulate  it  with  powerful  tools  in  a 
cooperating  information  system.  A  distributed  system  comprised  of  personal  computers, 
high-power  workstations,  and  minicomputers  all  networked  over  a  hi^-speed  channel  is 
becoming  standard  in  many  Air  Force  units.[3] 

Scheduling  Methods 

There  are  a  number  of  variations  on  scheduling  one  of  multiple  agents  to  one  of 
several  tasks  (i.e.,  scheduling  activities).  Scheduling  algorithms  discussed  in  the  literature 
generally  have  their  basis  in  one  or  more  (rf  operations  research,  traditional  AI  search,  or 
knowledge-based  greedy  heuristic  search  or  some  combiiuuion.^  The  systems  with  the 
most  impressive  performance  result  from  a  combination  of  scheduling  methods. 
Constraints,  both  soft  and  hard,  ate  pervasive  and  have  great  impact  on  scheduling 
algorithms,  especially  in  the  area  of  bottteneck  iesources.[5, 10]  Optimization  is  an  in^licit 
goal,  although  optimization  normally  means  different  things  to  different  evaluators  in  the 


^Hunun  Khedukn  lend  lo  nse  the  heuristics  iteratively,  with  iterations  occurring  only  after  a  sufHciently 
hardcoosnaintis  viofanedanddiacovered.  It  is  a  mistake  to  believe  that  human  plnnnm  consider  multiple 
alternatives,  especially  in  a  time-constrained  environment.[211 
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real  world  Schedule  flexibility,  constancy,  and  explainability  are  all  desirable  for  real 
world  systems. 

Algorithms  Based  on  Operations  Research.  Generally,  linear  programming  can  be 
applied  to  scheduling  problems  only  as  an  approximate  method  because  the  divisibility 
assumption  does  not  hold  That  is,  some  or  all  decision  variables  must  be  integer-valued  or 
binary.  In  addition,  some  scheduling  nxxlels  are  based  on  nonlinear  equations  which 
require  nonlinear  programming  teclmiques  to  solve.  Nonlinear  programming  can  become 
computationally  intensive;  integer  programming  is  not  too  bad  but  soft  constraints  are 
difficult  to  rtxxkl  and  solutions  tend  to  be  sensitive  (lack  consistency)  when  new 
constraints  are  added  Operations  research  methods  attempt  to  provide  a  global  maximum 
over  time,  but  in  many  domains,  the  worid  situation  changes  for  reasons  outside  of  any 
plan  (e.g.  machines  break,  orders  are  re-prioritized).  In  practice,  schedulers  based  on 
operations  research  algorithms  often  cannot  keep  up  with  unplanned  events  in  complex 
systems,  and  a  human  supervisor  must  intervene  to  repair  the  plan.  Operatitms  research 
algorithms  are  not  easily  explained  automatically.[S,  8, 9, 10, 12,  14,  18, 26,  38, 41] 

Algorithms  Based  oo  AI  Search.  Search  may  be  applied  to  find  a  satisfying  (or 
optimal),  robust  solution  based  on  sotL«;'  objective  function.  Search  techniques  include 
forgetful  backtracking  or  memory-intensive  depth-  or  breadth-first  forward  search.  The 
best  first  search  (A*)  may  be  applied  if  an  estimation  heuristic  can  be  defined  The 
objective  function  is  typically  knowledge-based  as  well.  These  search  techniques  are 
commonly  used  in  classical  AI  planning  systems  (generative  plaruiers)  to  generate  a 
solution  path,  and  they  work  the  same  way  for  scheduling  purposes.  The  A*  algorithm 
was  used  in  the  LISP  machine/KEE  version  of  the  RADC  Aircrew  Scheduler.[l  1, 28, 32] 
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Algorithms  Based  on  Heuristics.  If  enough  knowledge  can  be  derived  from  the 
particular  domain,  a  knowledge-based  scheduling  algorithm  may  be  developed  using 
heuristics.  Greedy  heuristics  are  those  that  improve  the  solution  the  most  at  the  point  they 
are  invoked.  An  example  of  a  greedy  heuristic  is  "schedule  a  pilot  who  has  less  than  five 
days  of  currency  remaining  without  taking  into  account  future  placement  possibilities." 
Like  search-based  methods,  heuristic  methods  deliver  robust,  flexible  solutions  which  can 
be  explained  by  a  little  extra  code.  These  AI  systems  differ  tiom  traditional  search-tviented 
models  by  the  degree  of  backtracking  or  search-memory  required.  Backtracking  is 
normally  required  only  when  constraints  are  changed  or  may  not  be  implemented  at  all. 
Some  rule-based  production  systems  are  good  examples  of  this  type  of  system.[5, 7, 32] 

Programming  Environments  and  Methodologies  for  die  Aircrew  Scheduler. 

Design  requirements  on  the  final  aircrew  scheduling  product  indirectly  constrained 
the  choice  of  programming  environment  (because  prototype  programming  environments 
often  become  delivery  envirorunents).  As  implied  by  earlier  discussion,  data  storage  and 
database  functionality  were  required  to  manipulate  the  half  megabyte  or  so  of  pilot  and 
schedule  data.  Several  different  types  of  data  representation  were  required.  lD:q)]ementing 
die  scheduling  algorithm  made  die  flexibility  of  a  general  purpose  programming  language 
desirable.  A  simple,  aesthetically  pleasing  interface  was  considered  mandatory  to  gain 
acceptance  by  the  user.  Specifically,  multiple  windows  were  thought  to  be  important  for 
inniitively  generating  different  data  views;  mouse  input  was  considered  very  desirable 
(pilots  prefer  pointing  devices  to  keyboards);  and  direct  editing  of  displayed  data  was  also 
needed.  The  entire  interface  had  to  be  rimple  and  natural,  with  menus  and  context- 
sensitive  help  available.  The  use  of  multiple  fonts,  color,  and  sound  were  considered  non- 
essential  bonuses  but  would  add  appeal.  The  entire  scheduling  system  had  to  run 
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acceptably  on  an  IBM  perscmal  computer;  portability  was  ccxisidered  an  unnecessary 
bonus. 


The  choice  of  programming  enviitximent  and  methodology  were  also  directly 
affected  by  the  coti^lexity  of  the  programming  project  and  the  relatively  short  time 
allocated  to  completing  it.  An  object-oriented  methodology  or  functinnal  programming 
approach  would  have  addressed  the  complexity  issue;  the  available  development  time 
pointed  toward  the  use  of  a  software  tool  for  building  scheduling  systems.  A  tool  is  a 
software  environment  consisting  of  a  higher  ordered  language  together  with  powerful 
functions  useful  for  rapid  development  of  a  specific  type  of  application.  Tools  cut 
development  time  by  raising  the  level  of  programming;  they  are  essentially  higher-  higher- 
ordered  languages.  For  example,  a  tool  for  building  expert  systems  might  be  Lisp-based 
but  have  functions  for  specifying  a  windowing  interface  and  an  object-oriented  knowledge 
representation  scheme  lacking  in  Lisp.  There  was  historical  in:q)etus  for  using  a  software 
tool  -  the  original  LISP  machine  version  of  the  aircrew  scheduler  was  built  on  KEE  which 
provides  graphics,  objea-generation,  and  procedural  functionality  over  and  above  the 
environment  of  a  LISP  machine.  Unfortunately,  generic  tools  often  restrict  flexibility; 
another  way  of  saying  this  is  that  they  lack  needed  functions  and  procedures.  Tools  ate 
useful  when  the  application  to  be  built  fits  entirely  within  the  scope  of  the  hig^-level 
capability  they  provide.  Furthermore,  the  tools  available  at  the  time*  were  not  ^prx^iiate 
because  high  licensing  fees  would  preclude  distribution.  Therefore  tools  were  not 
considered  further. 

The  choice  of  programming  methoddogy  depends  to  a  large  degree  on  tire  amount 
of  program  modification  that  will  be  required.  Scrftwate  has  a  life  cycle  that  differs  for 


*InteUicorp's  KEE  and  Gold  Hill  Computer's  Gold  Works. 
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different  applications,  but  the  stability  of  the  code  generally  increases  throughout  its  life 
cycle.  Different  types  of  software  have  different  life  cycles  and  different  levels  of  stability. 
For  an  application  with  a  large  user  base  like  a  commercial  word  processor,  there  is 
ecommoic  justificadon  fcv  releasing  a  very  coiiq>lete  product  that  will  require  few 
modificadons.  A  word  processor  may  be  prototyped  using  one  methodology  and  when 
complete,  the  prototype  is  ported  to  a  hardware-oriented  language  for  efBciency.  Unlike 
word  processors,  a  very  specific  application  like  a  single-seat  aircrew  scheduler  for  A-lOs 
has  a  very  small  user  base;  there  may  not  be  funds  fcff  release  of  a  complete  product,  but 
more  importandy,  specific  applications  require  user  input  not  available  to  the  software 
developer  before  release.  Therefore,  a  specific  application  like  an  aircrew  scheduler  is 
generally  released  sooner  in  the  life  cycle,  and  will  normally  require  modification.  A 
specific  plication  may  never  be  hard  coded  into  a  faster  language  because  of  lack  of 
funding,  the  need  fw  continuous  modification,  or  suitabili^  oi  current  executitm.  Artificial 
intelligence  applications  are  typically  voy  user-ispecific  because  cuirait  expert  systems  . 
have  narrow  domains.  Very  few  expert  systems  ever  get  out  of  the  development  stage  for 
the  reasons  stilted  above. 

If  the  programming  methodology  and  environment  oi  a  user-specific  applicaticm 
remains  with  and  is  delivered  as  part  of  the  application,  then  diere  is  another  factor  to 
consider  understandability.  User  acceptance  depends  on  user  understanding  of  the 
software.  This  is  especially  true  of  artificial  intelligence  applications.  Therefne,  the  more 
the  user  can  understand  how  the  program  arrives  at  an  answer,  the  better  the  chosen 
environment  If  users  can  understand  the  program  and  the  programming  methodtdogy  is 
simple  enou^,  they  may  even  be  able  to  modify  the  code  themselves. 

Higher  Ordered  Languages  (HOLs).  Standard  languages  like  Pascal  or  C  offer  the 
flexibility,  execution  speed,  power,  and  ptmability  required  for  the  end  product  scheduling 
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system.  The  primary  disadvantage  of  using  a  higher  ordered  language  is  that  many  needed 
functions  and  routines  must  be  programmed;  an  alternative  mol  might  provide  these 
functions  and  routines  and  thus  speed  development  The  tradeoff  between  speed  of 
develt^mient  and  flexibility  allowed  by  the  programming  environment  is  a  prime  design 
consideratioiL  Initially,  we  attempted  to  port  the  LISP  Machine/KEE  version  of  the  RADC 
Aircrew  Scheduler  to  KEE  running  on  a  COMPAQ  386  personal  computer  rurming  UNIX. 
That  effort  ground  to  a  halt  because  of  differences  in  KEE  versions  and  inflexibility  of  the 
COMPAQ  KEE  environment,  among  other  reasons.  Cur  second  porting  atten^t  used  the 
popular  and  powerful  Turbo  C  compiler.  We  made  progress  using  C,  but  development 
time  was  too  slow  to  meet  our  milestones.  Using  our  eventual  programming  environment, 
Microsoft  Excel,  we  were  able  to  achieve  in  3  days  the  same  functionality  that  had  taken  us 
20  days  worth  of  C  (ffogramming  earlier,  given  our  meager  programming  experience.  (See 
APPENDIX  B). 

Languages  like  Pascal  and,  more  particularly,  C  are  machine-oriented,  procedural 
languages.  They  guard  computer  memory  resources  diligently  and  ensure  fast  execution 
speeds  using  efficient  primitives  and  library  routines.  However,  they  require  the  user  to 
think  procedurally,  and  some  programmers  find  that  thinking  procedurally  stifles  creativity. 
Other  languages  have  been  developed  as  alternatives  to  inooedural  languages.  Declarative 
languages  like  Prolog  focus  on  a  specification  of  a  data  set  (like  relational  databases  do)  and 
use  a  built-in  backtracking  procedure  to  generate  query  responses.  In  fact,  it  is  easy  to 
irr^lement  a  relational  database  in  Prolog^;  Prolog  was  considered  as  a  possible  aircrew 
scheduler  development  environment  because  of  its  ability  to  answer  questions  which  arise 
when  using  a  heuristic  scheduling  methodoiogy.[23]  Functional  languages  like  LISP  and 
its  derivatives  (for  example.  Scheme)  are  similar  to  Pascal  and  C  in  some  respects.  LISP, 

^The  efficiency  of  a  reladonal  database  unfriemenied  in  Prolog  is  limited  by  the  linear  search  mechanism 
used  by  its  interpreter. 
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unlike  C  or  Pascal,  almost  demands  the  use  of  recursitxi  and  automates  memory  allocation 
and  reclamation.  LISP  was  developed  for  artificial  intelligence  programming  and  allows 
the  programmer  to  use  any  data  without  requiring  type  declarations.  LISP  has  a  simple 
syntax  composed  of  seven  primitives,  the  ones  of  primary  iiiq)ottance  to  programmers 
being  those  that  construct  and  select  (dissect)  LISP  data  objects  (lists).[l,17] 

Object-Oriented  Programming.  The  object-oriented  programming  paradigm  can  be 
used  in  almost  any  language,  but  languages  like  Smalltalk-80  enforce  it  The  object- 
oriented  trxxiel  is  data-centered,  promotes  data  abstraction  and  modularity,  uses  procedures 
bound  to  data  to  make  active  data  objects,  and  uses  messages  between  data  objects  to 
execute  a  program.  ^^[33] 

Experienced  programmers  tend  tt>  build  up  software  modules  that  are  later  reused. 
Commercial  C  lilxaries  ate  now  available;  LISP  programmers  tend  to  develop  whole 
"worlds"  of  procedures  useful  in  many  contexts.  A  primary  goal  of  object-oriented 
programming  is  software  module  development  and  reuse.  Software  reuse  requites  much 
documentation  (writing  and  reading),  but  saves  programming  time,  avoids  undetected 
erron,  and  standardizes  higher-level  functions.  The  distinction  between  a  "tool"  and  a 
programming  language  supported  by  an  extensive  library  is  getting  blurry,  but  "totd"  still 
implies  a  neater,  less  flexible  package.! IS,  33, 40] 

Visual  Progranuning.  Using  a  LISP  machine  or  a  Smalltalk  develt^mient  environment 
clearly  dononsttates  that  the  total  development  environment  impacts  program  development 
at  least  as  much  as  the  particular  language  chosen.  Specialized  programming  environments 
such  as  diese  are  typically  single-user  v^nkstadons  having  large  displays  with 


lOSee  APPENDIX  C. 
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windowing/menu  interfaces,  mouse  input,  and  seamless  integration  of  all  programming 
tools:  editor,  debugger,  context-sensitive  help,  and  compiler.  All  of  these  elements  of  the 
environment  aid  in  software  develt^ment  to  stxne  extent,  although  it  is  very  difficult  to 
quantify  the  effect  of  environment  attributes  on  software  development  Rather,  attribute 
"goodness"  must  be  described  qualitatively  and  subjectively.  Personal  preferences  and 
histories  have  an  impact  For  example,  many  programmers  (arKl  users)  would  agree  that  a 
mouse  coupled  with  a  point-and-click  interface  is  preferable  to  typing  a  response,  but  some 
never  use  a  mouse  because  they  can  type  faster  or  prefer  not  to  switch  from  keyboard  to 
mouse  and  back  again.  [2,  34] 

One  attribute  of  the  environment  the  display,  is  of  particular  importance  and  is  now 
recognized  as  an  imp(»iant  area  of  research  comnoonly  referred  to  as  visual  programming: 

)^th  die  availability  of  graphic  workstations  has  come  the  increasing 
influence  of  visual  teclmdc^  on  langua^  environments.  In  this  article  we 
trace  an  evolution  that  began  with  the  relatively  straightforward  translation  of 
textual  techniques  into  corresponding  visual  techniques  and  has  progressed 
to  uses  of  visual  techniques  that  have  no  natural  parcel  using  purely  textual 
techniques.  In  short,  the  availability  of  visual  technology  is  let^g  to  the 
development  of  new  approaches  that  are  inherently  visii^.[2] 

Visual  progtamiiiing  focuses  on  making  computer  systems  easier  for  pec^le,  rather 
than  enhancing  hardware  performance.  Part  of  the  impetus  for  paying  attention  to  visual 
interfaces  comes  from  the  widespread  use  of  personal  cranputers  by  nonprogrammers. 
Artificial  intelligence  research  and  expert  ^sterns  have  also  helped  make  interfaces 
important  Display  technology  has  advanced  to  the  pdnt  where  hi^-resolution  bit-mapped 
gr^rhics  are  available  to  almost  anyone.  Using  high  resolution  graphics,  a  more  visual 
mode  of  programming  is  possible  and  attractive.  Interactive  grtqrhics  has  die  potential  for 
making  input  and  output  not  only  meaningful,  but  fast  interesting,  and  flexible  as 
well.[34] 
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Why  are  vision  and  graphics  important  to  computer  input  and  output?  Humans  deal 
naturally  and  quickly  with  visual  input  and  not  so  easily  with  serialized,  one-dimensional 
text  or  speech.  One  reason  that  a  picture  conveys  so  much  more  information  than  a  stream 
of  words  is  that  the  "language"  of  pictures  is  a  much  richer,  truer  representation  of  objects 
in  the  real  worid.  Things  Uke  shape,  relationship  to  other  objects,  color,  and  texture  are 
instandy  recognized  in  a  scene  that  would  take  hours  to  fully  describe  verbally.  Another 
advantage  that  visual  images  have  over  text  strings  is  that  humans  can  focus  on  infomation 
they  find  interesting.  The  use  of  multiple  fonts  and  columns  (as  in  a  newspaper,  for 
example)  allows  a  reader  to  focus  on  information  of  interest.  In  contrast,  a  listener  must 
access  information  sequentially  (as  in  a  radio  news  broadcast),  waiting  for  the  desired 
infcnmation.  Both  of  these  reasons  result  in  a  higher  infOTmation  transfer  rate  for  visual 
images  than  for  one-dimensional  text  strings.  The  human  visual-processing  bandwidth  is 
much  wider  than  die  audio-processing  one.  Animated  pictures  are  an  even  better 
representation  of  dynamic  real  worid  objects.  Animation  further  increases  the  potential 
transfer  rate  of  information  to  humans.[34] 

Cuirendy,  programmers  use  a  variety  of  non-automated  visual  techniques  to 
support  inogramnting.  Among  these  are  ctMitrol-flow  representations,  like  flow  charts, 
Nassi-Shneiderman  diagrams,  state  diagrams,  and  Petri  nets.  Data  flow  diagrams,  which 
focus  on  data,  rather  than  algcxithms,  are  also  used.  In  addition,  noore  informal  drawinp 
are  used  to  help  visualize  the  state  of  the  system.  For  example,  student  programmers  often 
sketch  out  data  structures  like  linked  lists  and  trees  to  leam  how  they  must  be  manipulated. 
Even  when  the  concept  of  a  particular  data  structure  is  known,  drawings  are  often  used  to 
analyze  programs  and  fix  bugs.  Finally,  overall  program  structure  is  often  conveyed  as  a 
topological  arrangement  of  code  modules  (boxes)  as  are  used  for  tq)  level  diagrams.[16, 
34] 
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Program  Animation.  Some  programs,  particularly  simulations,  provide  an  animated 
representadon  of  the  world  being  modeled.  Programs  can  also  be  written  to  simulate  the 
internal  state  of  the  con^uter  through  animation.  Animated  programs  display  pertinent 
variables,  program  instructions,  and  their  interactions.  As  the  program  executes,  each  line 
of  code  is  shown  along  with  the  variables  it  accesses  and  the  changes  it  causes.  Animated 
programs  help  programmers  check  program  conrecmess,  analyze  execution  speed  in 
different  parts  of  the  program,  and  determine  which  sections  of  code  are  inherently  parallel 
by  explicitly  showing  what  the  program  is  doing.[2;  24, 29, 34] 

Graphical  Input  to  Programs.  Languages  are  being  developed  for  integrating 
graphical  images  along  with  text  as  input  symbols  or  ouq>ut  results  in  programming 
languages.  Some  of  these  developments  take  the  form  of  syntax-directed  editors  which 
provide  a  template  which  allows  for  "programming  by  exaiq)le"  and  syntactic  error 
checking.[2,34]  Otiiers  support  a  graphical  view  of  programming  by  allowing  the 
programmer  to  see  a  visual  representation  of  data  structures  or  code  in  execution.[6, 24, 

27, 34]  Windows  may  be  used  to  support  different  views.  Icons  are  used  in  some  tools  to 
assign  a  visual  abstraction  to  code  or  data.  Still  other  tods  are  useful  for  designing  and 
documenting  software,  or  generating  it  from  a  visual  specification.[34]  Newer  research 
has  focused  on  the  use  graphical  symbols  as  inputs  to  the  progransning  language  (either 

along  with  or  in  lieu  of  text).[6, 37]  The  use  of  symbols  to  iixiex  data  is  also  a  research 
topic. 


Principally  fiom  artificial  intelligence  research  and  man-machine  interface  design, 
the  impact  of  vision  on  coaqrating  environments  is  now  known  to  be  great  Seeing 
programs  and  data  reduces  the  complexity  of  both  by  providing  a  way  to  move  from  the 
abstract  to  the  concrete  very  easily.  The  field  of  visual  programming  languages  has  arisen 
as  a  result  It  turns  out  that  the  best  display  is  die  largest  display,  as  humans  already  have 
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the  ability  to  focus  attention  cm  important  parts  of  images.  Debuggers  and  spreadsheets[3S] 
are  examples  of  this  "more  is  better"  rule.[2, 34] 

Visual  programming  makes  it  easier  to  write  programs.  It  enhances  the 
programmer's  ability  to  debug  programs  while  miming  various  data  sets.  Thus,  validation 
and  verification  are  easier  in  a  visual  environment  Modifying  programs  requires  finding  a 
potion  of  code  causing  some  behavior  and  changing  it  to  alter  the  behavior.  Animation 
helps  the  programmer  find  the  code  causing  a  behavior,  and  a  visual  environment  sin:q>lifies 
writing  and  testing  new  code.  Therefore,  visual  programming  also  makes  it  easier  to 
modify  programs.  [13,  25,  36]. 
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CHAPTER  4 

A  VISUAL  PROGRAMMING  METHODOLOGY 
BASED  ON  MICROSOFT  EXCEL  ON  THE  MACINTOSH 

The  new  aircrew  scheduling  prototype  is  based  on  Microscrft  Excel,  a 
spreadsheet/database/language  with  a  spreadsheet  interface.  By  using  Excel,  the  new 
scheduler  is  portable  to  IBM/MS-DOS  personal  cou^uters  or  Apple  Macintosh  computers. 
The  principle  development  was  done  on  a  Macintosh  Ilex.  The  methodology  used  to 
construct  the  Excel  prototype  is  described  in  detail  below. 

A  visual  programming  methodology  based  on  the  environment  provided  by 
Microsoft  Excel  has  two  cornerstones.  One  is  the  continuously  updated  display  oi  a  two- 
dimensional  data  array,  the  most  t^arent  feature  of  any  spreadsheet  The  second 
cornerstone  is  program  animation  resulting  from  using  a  particular  style  of  programming. 
Both  features  make  program  development  and  debugging  easier  by  making  data  structures 
and  program  execution  eiqilicit  in  a  visual  sense. 

Excel  is  an  integrated  tool  having  spreadsheet  utility,  but  also  featuring  an 
interpreted  macro  programming  language,  graphics  routines,  and  a  powerful  library  of  user 
fiinctions.^^  The  database  functions  are  the  primary  ones  useful  for  programming 
scheduling  systems  in  Excel  Using  the  database  functions  and  the  rnacro  progratntning 
language,  a  heuristic  scheduling  system  widi  a  sophisticated  visual  intoface  may  be  written 
with  only  a  few  hundred  lines  of  code. 


^  ^Excel  is  representative  of  several  spreadsheets  having  similar  functionality.  Many  comments  made  about 
Excel  «e  also  trae  of  other  spreadsheet  products. 
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Excel  also  supports  graphical  programming  methods  for  generating  dialog  boxes. 
These  interactive,  graphical,  user  input  windows  further  refine  the  overall  interface  and 
make  the  program  even  easier  to  use. 

The  visual  programming  methodology  described  is  based  on  wide-bandwidth 
ouq;)ut  and  animated  execution,  but  takes  full  advantage  of  all  attributes  of  Excel,  including 
the  windowing  operating  system  it  resides  on  and  other  attributes  of  the  Macintosh: 
graphics,  mouse,  and  built-in  networking. 

A  Visual  Programming  Methodology  Using  Excel.  The  general  methodology 
used  is  outlined  below  and  discussed  in  the  following  sections. 

1.  Without  regard  to  procedures  required,  generate  the  applicable  data  structures  in 
portions  of  the  Excel  spreadsheet  array.  Use  concrete  representations  which  are  as  similar 
to  the  modeled  data  structures  as  possible  Group  related  data  structures  in  appropnatc 
locations  in  the  spreadsheet  array.  Fill  the  data  structures  with  real  or  exanqple  data. 

2.  Make  full  use  of  fiuctional  progranuning  to  display  abstract  data. 

3.  Using  die  continuous  display,  noouse,  and  available  commands,  manually 
manipulate  the  data  to  learn  how  to  cause  the  desired  program  behavior  as  needed. 

4.  Using  available  functkHis,  write  small  program  modules  to  incrementally 
automate  data  manipulations.  Group  related  program  modules  in  appropriate  locations  in 
the  two-dimensional  program  area.  Modules  should  be  called  as  subroutines.  Access  data 
only  by  visiting  its  location  to  provide  animation.  For  example,  move  data  using  'select- 
copy-select-paste.'  Continue  until  data  manipulation  is  fully  automated,  testing  modules 
using  animation.  Rearrange  data  structures  and  program  modules  as  appropriate. 

5.  Generate  the  user  interface  by  graphical  dialog  box  programming  and  menu  bar 


commands. 
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Excel's  Interface.  Like  other  spreadsheets,  Microsoft  Excel  displays  an  array  of  data 
cells  which  are  continuously  updated,  should  they  contain  a  fonnula.  Higher-ordered 
languages  (HOLs)  like  C,  Pascal,  and  Ada  require  extra  progranuning  to  get  ouq>ut,  but  a 
spreadsheet  interface  is  always  the  same  (with  minor  variations):  maximum  output.  The 
programmer  must  only  determine  how  to  partition  the  data  array  into  a  useful  display. 

Data  structures  in  Excel  are  visually  explicit,  in  conu^t  to  the  hidden  ones  in  C  or 
-  Pascal.  Novice  students  learning  about  ctxnputers  are  often  told,  "Computer  memory  is 
like  a  row  of  mailboxes  at  post  office.  Each  mailbox  has  a  physical  address  which  the 
computer  knows  about.  Each  mailbox  has  space  to  stcre  data  in.  You  name  the  mailboxes 
so  that  you  can  access  the  data  in  them."  Thus,  the  abstract  notion  of  assignment  becomes 
concrete  and  understandable.  In  a  Pascal  program,  the  assignment  mi^t  be  "A  s  B  +  1;" 
and  suddenly,  the  notion  is  abstract  again.  What  is  value  of  B?  What  does  A  look  like? 
(Perhaps  A  is  an  array!)  Arrays,  linked  lists,  and  trees  all  had  to  be  drawn  and  visualized 
by  every  programmer  who  now  understands  them,  yet  in  the  language,  these  structures  are 
invisible.  No  wonder  it  is  so  difficult  to  program  using  them!  A  mental  image  of  what  is 
gdng  on  is  constantly  required.  What  happens  when  the  number  of  variables  becomes 
large?  (Questions  like  "What  is  the  value  (rf  B?"  begin  to  slow  progress.  Those  questions 
are  not  so  difficult  when  their  answers  are  continuously  displayed. 

Part  of  the  represaitatitxial  complexity  of  programs  comes  from  data  structures  (the 
remainder  coines  from  algocithrns).  The  more  concrete  a  data  structure  is,  the  easier  it  is  to 
understand.  For  many  data  structures  and  some  real-world  things  (e.g.,  schedules),  a 
visual,  twoKlimensional  array  is  a  more  concrere,  truer  representation  than  the  invisible  data 
structures  available  in  Pascal  or  C  In  Excel,  an  array  looks  like  die  array  we  visualize  in 
Pascal  (at  least,  to  two  dimensions).  A  linked  list  in  Excel  looks  natural  also,  and  it  is  a  lot 
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tougher  to  get  lost  in  an  explicit  one.  A  real-world  schedule  is  often  represented  as  a  table; 
an  Excel  schedule  can  lode  identical. 

Because  of  the  two-dimensional  array  displayed.  Excel  lends  itself  to  two- 
dimensional  data  structures.  Two-dimensional  data  structures  include  single  variables  (1  x 
1  arrays),  one-dimensional  arrays  (n  x  1  arrays),  two  dimensional  arrays,  and  tables, 
relational  database  tables  included.  With  a  litde  ima^nadon  (using  relative  pointers),  liideed 
lists,  stacks  aixl  queues  (as  n  x  1  arrays)  can  be  implemented.  Higher  dimensional  arrays 
and  trees  are  difficult  to  implement  as  visually  explicit  structures.  For  writing  "real  world" 
applications,  lack  of  support  foe  higher  dimensional  data  structures  can  be  unimportant; 
many  "teal  woild"  data  structures,  such  as  invoices,  bank  statements,  time-tables,  etc,  are 
inherently  two-dimensional  because  diey  are  expressed  on  paper  or  some  other  two- 
dimensional  surface.  For  example,the  data  structures  most  used  fw  scheduling  are  a 
schedule  (a  table)  and  reladcmal  database  schema  (other  tables). 

In  Pascal  or  C  variables  are  typed  and  allocated  by  name.  After  that  they  may  be 
used  in  the  program.  Strong  typing  allows  for  some  error  checking  and  allows  efficient 
use  of  memory.  However,  in  the  iterative  style  of  most  programmers,  there  is  a  necessary 
cycle  between  the  discovery  of  the  need  for  a  variable  and  its  required  typing  and 
allocation.  Languages  such  as  LISP  require  no  typing  and  allocate  using  definitions  at  run 
time.  In  ExceL  typing  is  discovered  by  the  system  from  syntax  (as  in  BASIC),  and 
allocatioii  is  made  incrementally  as  data  is  entered  into  eadi  oelL  Furthermore,  each 
location  where  data  may  be  stored  has  a  default  name.^^  Thus,  the  programmer  never 
needs  to  scroll  back  to  the  top  of  a  file  to  allocate  additional  variables,  as  in  C  or  Pascal.  In 


^^A12  or  B3,  for  example.  User  specified  names  are  also  supported. 
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practice,  it  is  more  natural  to  put  data  and  data  structures  onto  the  spreadsheet,  and  write 
programs  to  manipulate  them  afterwards. 

In  Excel,  single  variables,  higher  data  structures,  and  algorithms  are  all  physically 
located  someplace  on  the  two-dimensional  spreadsheet  For  example,  one  subroutine  may 
be  east  west  north,  or  south  of  another.  This  is  fimdamentally  different  from  a  language 
like  C  CfT  Pascal  In  C  or  Pascal,  data  structures  are  invisible,  existing  somewhere  in  the 
ether  of  the  computer’s  memory;  algorithms  are  a  little  better  off,  existing  in  a  linear  (one¬ 
dimensional)  text  file.  By  inserting  white  space,  Pascal  and  C  algorithms  can  be  written 
with  addec  iimensiondity.  In  other  words,  properly  indenting  code  can  give  additional 
meaning;  thus,  much  of  the  power  of  structured  programnung  arises  because  of 
appearance,  a  visual  extension  the  one-dimensional  alternative.  However,  indented  code 
is  not  really  two-dimensional  in  the  same  sense  as  Excel  programs  can  be.  In  Pascal,  one 
code  module  must  come  before  or  after  another.  The  added  dimensionality  in  Excel 
provides  additional  impetus  to  write  modular  code  for  cognitive  reasons  (discussed  below). 

From  a  cognitive  standpoint,  Excel's  visual,  two-dimensional  spreadsheet  interface 
is  far  superior  to  the  ptDgrammipg  envircmment  oi  typical  higher-ordered  languages.  The 
primary  advantage  of  a  ^xeadsheet  interface  is  that  additional  associatkxis  are  possible  that 
relate  a  data  structure  or  piece  of  code  to  familiar  objects.  There  are  three  practical  benefits 
which  result  First  it  is  easier  to  find  a  data  suucture  or  a  piece  of  code  because  the  data  or 
code  always  has  some  relation  to  what  is  known  (visible).  In  a  traditicxial  HOL,  "finding  a 
data  structure"  has  no  meaning,  but  fiixling  a  piece  oi  code  equates  to  scrolling  a  particular 
distance  fipom  die  current  cursor  positioa  The  difference  between  finding  something  in 
Excel  versus  Pascal  or  C  is  somewhat  analogous  to  navigating  by  map  as  opposed  to 
getting  directions.  Directions  tell  you  how  far  to  go  on  a  one  dimensional  route  before 
taking  some  action  (e.g.,  turning),  while  using  a  map  allows  the  use  of  external  points  of 
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reference.  A  second  benefit  of  two-dimensional  associations  is  added  flexibility  in 
structuring  programs.  Different  arrangements  are  possible.  A  top-level  design  diagram 
may  be  implemenred  in  simUaiiy  arranged  code;  alternatively,  code  modules  may  be 
arranged  hierarchically.  The  methodology  used  to  create  die  Excel  scheduling  prototype 
only  requires  related  code  modules  to  be  placed  close  together  in  some  natural  order.  A 
third  benefit  fix>m  extra-dimensional  associadons  arises  from  the  way  human  memory 
functions.  Remembering  a  piece  of  information  is  related  to  the  number  and  strength  of  the 
associations  attached  to  it  which  relates  it  to  something  else  already  in  memory.  For 
example,  mentally  picturing  a  new  acquaintance  standing  with  old  friends  with  the  same 
name  is  a  common  procedure  for  learning  names  at  a  coclctail  party.  Current  HOLs  attach  a 
name  to  a  Hata  structure  or  procedure,  although  a  procedure  has  a  second  memory 

"handle,”  its  locaHbn  is  in  a  linear  text  file.  In  Excel,  both  data  structure 

have  at  least  diree  handles:  absolute  cell  address,  user-defined  name  (if  one  is  assigned), 
and  a  relative  position  from  some  other  cell  Note  that  the  last  handle  is  really  many 
handles,  e.g.,  a  variable  called  'current  pilot'  in  cell  F19  is  3  cells  west  of  'current 
comment',  12  cells- northeast  of  'priority  pilot',  etc.  ad  infinitum.  The  utility  of  the  extra 
memory  handles  is  entirely  semantic  but  is  closely  tied  to  locating  code  and  structuring  it 
Six  montiis  after  writing  a  procedure,  not  only  can  it  be  found  and  known  to  be  related  to 
an  adjacent  procedure,  but  its  meaning  and  function  may  also  be  recaUed  (e^^ecially  when 
the  meaiung  of  adjacent  procedures  is  known).  Because  of  this,  writing  code  in  a  modular 
fashion  does  not  add  to  the  complexity  of  the  program  as  much.  Modularity  combats 
complexity,  but  the  overhead  ci  remembering  what  all  the  modules  do  can,  at  some  point, 
begin  to  add  complexity  of  its  own.  Because  modularity  is  well  supported  by  the  Excel 
environment,  it  is  also  a  goal  of  the  visual  programming  methodology  described. 

Control  Structures.  The  Excel  aircrew  scheduling  prototype  makes  extensive  use  of 
IF-THEN-ELSE,  subroutines,  and  GOTO  control  structures.  Excel  has  a  WHILE 
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primitive,  but  most  modules  are  so  small  that  the  GOTOs  used  do  not  cause  too  many 
problems  because  they  are  restricted  to  the  module.  Going  outside  the  module  should  be 
done  using  a  subroutine  call,  under  the  methodology  used.  Using  small  modules  keeps 
branching  limited.  Although  this  is  the  most  natural  type  of  stmctured  programming 
supported  by  Excel  (petiiaps  with  the  GOTOs  replaced  by  WHILE),  it  occasionally  made 
modules  slightly  longer  than  necessary.  Program  branching  can  make  code  smaller,  but  it 
can  also  add  con:^)lexity. 

Data  Structure  Design.  When  programming  a  solution  to  an  unfamiliar,  complex 
problem,  its  not  clear,  from  the  start,  what  data  is  important,  what  data  structures  are 
suitable,  or  what  the  relatitxiships  between  data  structures  are.  Using  a  visually  explicit 
language  like  Excel  allows  one  to  begin  programming  before  having  a  complete 
understanding  of  the  problem  and  aids  understanding  along  the  way.  This  approach'  was 
used  during  development  of  the  Excel  aircrew  scheduler  First,  the  data  thought  to  be 
important  was  arranged  in  tables  or  simple  variables  in  a  way  thought  to  be  ctxnecL  Then, 
simple  programs  were  written  to  manipulate  the  data  and  discover  what  manipulaticxis  were 
possible  and  natural  This  process  uncovered  several  important  relationships  between  data 
structures  and  showed  what  additional  data  and  data  structures  would  be  useful.  The  two- 
step  process  was  iterated  a  number  oi  times  to  arrive  at  a  reasonable  product 

Program  Animatioit  In  Excel,  there  is  always  an  active  cell  and  a  selected  array  of 
cells,  just  as  there  is  always  some  location  stored  in  the  program  counter  of  a 
mkroprocessor.  (The  selected  array  may  be  just  the  active  cell  a  1  x  1  array).  Macro 
programs  whkh  operate  on  Excel  data  use  the  active  cell  and  selected  array  to  access  data  in 
a  fashion  very  similar  to  the  way  a  mkrc^rrocessor  gets  data  from  memory  (one  byte  ac 
word  at  a  time).  While  this  arrangement  appears  rigid  (and  can  be  overcome),  it  forces 
explicit  manipulation  of  displayed  data.  By  diffetentiating  die  active  cell  and  selected  array 
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firom  other  cells,  animated  programs  are  possible.  In  Excel,  the  active  cell  is  outlined  in 
color  and  the  selected  array  (except  for  the  active  cell)  is  filled  in  with  color.  By 
programming  Excel  to  visit  each  data  cell  to  access  it,  the  active  cell  will,  during  program 
execution,  move  around  on  the  spreadsheet  data  array,  thereby  showing  the  programmer 
exactly  what  it  is  doing.  For  example,  a  typical  operation  is  to  move  data  from  one  cell  to 
another  (for  example,  the  criteria  array).  To  do  this  in  Excel,  a  four  line  program  is  needed 
to  select  the  first  cell,  copy  its  contents,  select  the  second  cell,  and  paste  die  contents  of  the 
first  cell.  The  ‘select-copy^select-paste'  program  appears  as  a  three  step  visual  program 
wherein  the  active  cell  visits  the  cell  to  be  copied,  visits  the  cell  to  be  pasted,  then  pastes  the 
value  of  the  first  cell.  Using  this  methodology,  every  time  a  program  runs,  the 
programmer  sees  which  data  cells  are  visited  and  what  changes  occur  to  cells. 

Furthermore,  Excel  has  a  single  stepping  feature  which  allows  the  programmer  to  slow 
execution  to  see  just  what  effect  each  line  of  code  has. 


The  program  animation  oossibilities  using  Excel  makes  it  very  easy  to  debug  a 

program.  The  programming  process  is  also  much  improved  because  it  is  simple  to  see 
inefficient  pathways  to  the  same  end. 

Rearrangements  of  Data  and  Programs.  Excel  uses  relative  addressing  as  a  default 
means.  Relative  addressing  is  more  natural  than  absolute  addressing  if  data  is  going  to  be 
moved  around.  Excel  expects  rearrangements  of  data  and  provides  for  it  in  sophisticated 
ways.  For  example,  data  arrays  may  be  cut  and  pasted  elsewhere  on  die  spreadsheet 
When  data  is  cut  aiKl  pasted,  all  references  to  it  in  any  Excel  file  are  transferred  to  the  new, 
ccnrect  address.  Functions  on  the  spreadsheet  which  return  data  values  also  refer  to  new 
addresses,  making  it  possible  to  cut  a  function  from  one  cell  and  paste  it  into  a  large  array. 

The  formulas  pasted  into  the  array  all  return  different  values  because  they  use  relative, 
rather  than  absolute  references.  Easy  rearrangement  promotes  modular  programming. 
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supports  experimentation  with  different  data  structures,  and  supports  experimentation  with 
the  physical  layout  of  code  and  data  structures.[30, 31] 

Verification  and  Validation.  The  combination  of  visually  explicit  data  structures  and 
animated  program  execution  are  powerful  tools  fw  verification  and  validation  (V& V). 

There  are  a  number  of  static  and  dynamic  methods  for  ensuring  V&V  for  traditional  and 
artificial  intelligence  software.  Static  methods  include  anomaly  detection,  structured  walk¬ 
throughs,  and  mathematical  proofs  of  program  specification  and  correcmess.  Dynamic 
methods  include  random,  regression  and  through  testing.  Static  analysis  of  data  structure 
and  algorithms  is  directly  related  to  their  visibility,  a  metric  of  relative  obscurity.  Visual 
programming  methods  allow  the  easiest  static  analysis  of  data  structures  due  to  their  explicit 
representation.  Proofs  of  program  correctness  are  generally  too  cumbersome  for  ccxnplex 
software.  Routine  testing  has  been  found  to  be  one  of  the  most  effective  V&V  methods, 
especially  for  artificial  intelligence  applications.  All  testing  metiiods  are  simple  when  the 
program  displays  itself  executing  as  Excel  programs  do.[ 13,25,36] 

Graphical  Programming.  Excel  supptvts  graphical  programming  fOT  generating  data 
for  interface  dialog  boxes.  The  Excel  dialog  editor  displays  an  entity  dialog  box  and  the 
programmer  may  add  elements  such  as  list  boxes,  option  boxes,  cancel  and  accept  buttons, 
and  text  fiom  a  menu.  The  dialog  box  and  its  elements  may  be  resized  and  moved  using 
the  mouse.  When  an  acceptable  interface  is  designed,  the  data  which  creates  it  can  be  cut 
and  pasted  into  an  Excel  spreadsheet  Then  a  <»ie  line  program  will  generate  the  interface 
and  user  iiq)uts  are  stored  as  data  next  to  the  inttrfaoe  data.  Additional  lines  ci  code  are 
required  to  access  stmed  user  inputs. 

Use  of  Database  Functions.  Although  not  part  of  the  visual  programming 
methodology,  use  of  Excel's  fourth-generation  functions  make  many  applications  simpler 
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to  program.  In  the  case  of  scheduling,  the  database  functions  are  most  inqxirtant  To 
heuristically  select  tuples  from  a  database  based  on  information  in  a  schedule,  items  frcxn 
the  schedule  (e.g.,  qualification)  may  be  pasted  into  the  criteria  array.  This  is  one  method 
of  applying  a  constraint  to  push  solutions  into  a  feasible  region.  Database  functions  such 
as  selection,  the  number  of  satisfying  tuples,  the  maximum  or  minimum  of  an  attribute 
column,  and  extraction  (projection)  all  use  the  current  criteria  array  to  select  tuples  and 
make  programming  easier  by  raising  the  level  at  which  it  is  done.  For  example,  a  very 
simple  aircrew  scheduler  rttight  be  based  solely  on  training  need.  To  implement  the 
scheduler,  a  pilot  database,  schedule,  and  algorithm  are  needed.  One  algorithm  which 
satisfies  the  requirement  would  copy  the  mission  type  firom  the  schedule,  go  to  that  mission 
type  in  the  criteria  array,  and  paste  in  the  maximum  value  of  the  corresponding  mission 
cdumn  in  the  database.  That  action  would  constrain  a  database  selection  to  the  pilot  with 
the  largest  training  requirement  for  the  mission  under  consideration.  The  algorithm  would 
singly  selea  die  pilot  name,  copy  it,  and  paste  it  in  the  schedule.[30,31] 

Windowing,  Menus,  and  Mouse.  The  Macintosh  environment  is  a  visual  operating 
system.  The  use  of  windows,  a  standardized  pull-down  menu  interface  across  all 
applications,  and  noouse  input  all  ocmtribute  to  the  ease  of  using  any  application.  The 
integration  between  applications  epitomized  by  die  ability  to  cut  and  paste  infonmtion 
between  applications  is  very  helpful  during  application  develt^moent  and  use.  Graphical 
iccms  are  mote  meaningful  than  text  identifiers  when  it  comes  to  file  manipulation.  The 
mouse  sinqilifies  the  user  intoface  for  most  applications  and  allows  file  icons  to  be 
manipulated  in  a  natural  way.  In  Excel,  using  the  mouse  to  select  and  move  data  is  much 
simplCT  and  faster  dian  using  the  cursor  keys. 
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CHAPTER  5 

THE  EXCEL  AmCREW  SCHEDULING  PROTOTYPE 

Using  the  visual  prognumning  methodology  based  on  Microsoft  Excel  described  in 
the  last  chapter,  the  functionality  of  the  LISP  Machine/KEE  version  of  the  RADC  Aircrew 
Scheduler  was  ported  to  run  in  Excel  on  the  Apple  Macintosh  Hex.  (Excel  also  runs  under 
Mlcrost^  Windows  on  IBM  personal  computers  and  under  Sun-OS  (a  Unix  derivative)  on 
a  Sun  workstation). 

Design  Considerations.  To  gain  user  a<x:eptance,  the  Excel  aircrew  scheduler 

prototype  was  designed  to  do  aircrew  scheduling  in  die  same  way  as  the  current  manual 

mediod.  The  focus  was  not  on'  improving.the  current  scheduling  algorithm,  but  on 

knproving  the  communication  and  presentadon  of  data,  providing  analysis  capability,  and 

automating  the  current  algorithm.  By  aummating  the  heuristic  scheduling  algtmthm  used, 

the  con^uter  can  aid  the  scheduling  officer  by  finding  t^ipn^niate  pilots  and  never 

♦ 

fOTgetting  constraints.  Using  this  approach,  die.ctm^uter  is  allowed  to  do  what  it  does 
well  (i.e.,  store  and  manipulate  data)  and  the  scheduling  officer  is  left  to  do  what  he  does 
well  (handling  amxnalies  and  detennining  smarter  ways  d  doing  things).  Heavy  emphasis 
was  placed  on  allowing  the  user  to  have  control  of  the  system.  For  each  action 
implemented,  there  is  an  analogous  procedure  for  retracting  it  An  uninhibited  display 
attitude  was  a  prime  design  requirement  ftom  the  start  and  Excel's  constant  ouqxit  d  all 
data  and  ftmctional  results  siq>pofied  that  requirement  well.  There  was  some  concern  that 
the  user  would  be  flooded  with  data,  but  humans  are  well  tuned  Sor  focusing  on  ^xdiat  they 
consider  impentam,  and  scheduling  offices  have  not  complained  thus  far.  Using  die 
standard  window  interface,  the  user  can  access  mcne  data  by  simply  scrolling  the  window. 
Editing  is  important  for  changing  schedule  data,  and  the  direct  editing  interface  supptnts  the 
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user's  need  for  natural  interaction.  Also,  the  same  animation  that  helped  the  program 
develq)er  build  the  prototype  will  help  the  scheduling  officer  understand  exactly  what  the 
proto^pe  is  doing  and  thus  build  confidaice  in  its  scheduling  choices.  Because  Excel 
exists  in  a  windowing  environment,  multiple  user  views  are  possible,  including  one  which 
minimizes  die  animation  window,  should  it  become  boring.  The  prototype  has  been  built 
making  maximum  use  of  graphical  dialog  boxes,  resulting  in  interactive  routines  diat  are 
sinqile  point-and-click  operations. 

System  Description  of  the  Excel  Aircrew  Scheduler  Prototype: 

Data  Structures.  Gmsolidated  database.  The  current  Excel  prototype  has  a  database  of 
pilots,  dieir  qualifications,  event  ccm^letions  for  the  cutent  training  term,  and  currency 
days  remaining  for  each  event  (basic  AFORMS  data).  (SeeHgure2.)  In  addition,  the 
conscdidated  data  base  includes  a  row  for  preferences  and  the  availability  status  of  each 
pilot  based  on  the  mission  under  consideration,  pilot  availability  data,  and  timing  constraint 
data.  (SeeRgureB.)  Timing  constraint  data  are  those  data  items  which  arise  firom  the 
length  of  flying  day  and  crew  rest  constraints.  This  data  is  added  onto  (i.e.,  linked  with) 
tuples  in  tiieconsdidated  data  base.  Pilot  availability  data  is  stored  in  a  linked  list  which  is 
also  attached  to  tiqiles  in  the  database.  Pilot  availability  status  iq)pearing  in  the 
consolidated  database  is  actually  the  result  of  a  function  operating  on  availability  and  timing 
constraint  data,  using  current  mission  start  and  stop  times.  Thus  the  abstract  notion  of 
availabili^  that  the  user  has  in  mind  is  the  actual  data  presented,  and  the  details  how 
availability  is  calculated  are  buried. 

Associated  with  the  consolidated  database  is  a  criteria  array  used  to  specify  criteria 
fOT  selecting  data.  (See  Figure  2.)  It  is  composed  of  attributes  from  the  consolidated 
database  and  is  displayed  in  tabular  fona  Because  there  is  a  one-to-one  cturespondence 
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between  cdumn  headings  (attributes)  in  the  criteria  anay  and  die  ccMisolidated  database,  the 
criteria  array  is  physically  located  directly  below  the  consolidated  database  for  aesthetics. 
There  are  two  areas  below  the  criteria  anay  used  as  a  swap  space  for  the  cunent  criteria.  In 
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addition,  there  is  an  array  below  event  and  currency  attributes  in  the  criteria  which  hold 
maximum  and  minimum  values  of  corresponding  database  attribute  tuples.  Again, 
"maximum"  and  "minimum"  are  abstractions,  the  result  ai  functions. 

The  partial  schethile  to  be  filled  is  presented  as  a  table  containing  schedule  line 
number  (a  key),  take  off  time,  landing  time,  mission  type,  pilot  qualification  requirement, 
aircraft  configuratitMi  and  range  data  for  each  sortie.  (Seelngure4.)  There  are  slots  left 
open  in  the  schedule  for  pilot  and  scheduler  comments.  The  schedule  flight  date  and 
schedule  generation  date  are  attached.  Today’s  date,  the  result  of  a  function  using  the 
computer  system  clock,  is  displayed  and  may  be  ccq)ied  into  the  schedule  generation  date. 

The  pritHi^  list  for  the  schedule  appears  as  a  table  but  is  dynamically  converted  to  a 
database  during  program  execution.  (See  Figure  4.)  It  contains  relative  priority  number, 
pilot,  mission,  and  a  requirement  cranment,  if  desired,  fiom  the  supervisor  who  generated 
it  (typically  the  training  officer  or  DO).  There  is  an  attribute  heading  for  a  comment  by  the 
scheduler  because,  when  a  supervise  establishes  a  priority,  the  scheduling  officer  needs  to 
communicate  how  the  priority  was  treated.  As  with  the  consolidated  database,  there  is  a 
criteria  array  associated  widi  the  priority  list  (priority  list  criteria)  contairiing  the  same 
attribute  headings  and  located  directly  below  the  pticni^  list  In  addition,  there  is  an  area 
below  the  priority  list  criteria  used  to  extract  (project)  the  priority  number  and  pilot  name 
fiom  the  priority  list  based  on  the  selection  criteriem. 


Flight  data  are  di^layed  in  another  table.  (SeeHguteS.)  This  data  specifies 
which  sorties  are  parts  of  which  flights.  Two-  and  four-ship  flights  are  common,  although 
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Figure  4.  Partial  Schedule  and  Priority  List 
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other  ctxifigurations  are  possible.  The  configuration  of  die  flight  dictates  what 
qualificadons  are  required  by  the  flight  leaders.  For  example,  a  two-ship  flight  would 
require  a  two-ship  flight  leader,  but  a  four  ship  flight  would  require  a  four-ship  flight  leader 
as  well  as  a  two  ship  flight  leader  because  tactical  aircraft  normally  fly  in  pairs  (leader  and 
wingman).  Giirendy  the  flight  data  are  used  only  to  reset  pilot  qualification  when  pilots 
are  removed  fixmi  the  schedule. 

There  are  four  tables  which  help  the  system  provide  different  data  views  to  the  user. 
Three  of  them  result  from  projecting  data  from  the  ctmsolidated  data  base.  Pilot 
qualification,  event  requirements,  and  event  currencies  may  be  viewed  as  tables  or  graphs 
using  these  projections.  The  fourth  table  is  a  manipuladon  oi  the  pilot  availability  data  used 
to  create  a  time  line  chait  of  pilot  availability.  (See  Figures  6, 7,  and  8.) 

There  are  other  abstractions  displayed  and  used  by  die  program.  Among  diese  are 
size  data  for  the  consolidated  database  and  the  number  of  pilots  from  the  consolidated 
database  who  meet  the  cuirent  criteria.  There  is  a  vector  of  match  values  for  the  availability 
data.  The  match  values  are  used  to  update  data  and  as  an  intennediate  result  for  availability 
calculation.  Other  data  that  are  displayed  and  used  are  the  number  of  days  remaining  in 
currency  before  the  scheduler  becomes  concerned  and  the  last  DNIF  times. 

Most  arrays  used  are  not  the  typical  Pascal-like  array  but  rather  dynamic  data 
structures  which  may  expand  in  length  or  width.  The  oxisolidated  database  lengthens  by 
the  addition  of  pilots  (tiqiles)  and  widens  by  the  addition  of  training  events.  The  associated 
oiteria  also  otpands  in  widdi  when  training  events  are  added.  The  availabiliQr  data  stored 
in  linked  lists  attadied  to  each  pilot  (tuple)  are  able  to  expand  to  the  limits  of  monory; 
however,  cunent  algorithms  used  do  not  take  into  account  more  than  five  blocks  of  free 
time  or  occupied  time  for  a  day.  This  limit  is  considered  adequate  for  tracking 
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availability  and  was  chosen  to  constrain  file  sizes,  but  it  may  be  easily  changed.  The 
schedule  will  obviously  be  longer  or  shelter  depending  on  the  number  of  scheduled  sorties. 
The  length  of  the  priority  list  is  also  variable.  The  four  tables  derived  from  odier  data  are 
also  dynamic.  All  program  modules  have  been  written  to  take  into  account  die  dynamic 
nature  of  die  data  structures  used. 
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Air  Combat  Training  Event  Requirements  and  Currency  Days 


■  ACSr  □  ACBT  Cur  Days 


Figure  7.  Example  Analysis  Cnq)h 

Data  Representatkms.  Data  S4)pearing  on  the  interface  window  are  either  of  simple 
type,  such  as  numbers,  dates,  or  character  strings,  or  an  abstraction,  the  result  oi  a  fimction 
applied  to  odier  data.  Simple  data  may  be  edited  directly  without  possibility  of  error. 
Abstractions  may  also  be  edited,  but  the  details  of  the  function  are  presented  in  the  editing 
window.  To  edit  screen  objects,  the  user  mouses  on  it  (points  to  it  and  clicks)  to  select  it 
When  it  appears  in  the  editing  window,  normal  editing  commands  are  available  and  a 
carriage  return  con^letes  editing. 
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Figures.  Pilot  Availability  Timeiine 

Pilots  are  represented  by  a  string  consisting  of  their  names  in  the  format  ^own.  The  user 
must  only  type  the  name  in  once;  thereafter,  the  name  may  be  nx)re  easily  ct^ied  and 
pasted.  Pasting  names  is  useful  when  the  user  wants  to  manually  insert  a  pilot  into  die 
schedule.  Pilot  qualification  levels  are  mai^ied  to  numbers  in  the  following  way:  those  in 
mission  qualification  training  ate  level  1,  those  who  ate  mission  ready  ate  level  2,  two-ship 
flight  leaders  are  level  3,  four-sh^  flight  leaders  are  level  4,  and  instructor  pUots  are  level 
S.  This  mapping  is  useful  for  selecting  pilots  with  at  least  some  level  of  qualification  and  is 
simple  for  humans  to  assimilate.  Pilot  availability  is  displayed  as  either  "Free"  or 
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Figure  9.  Automatically  generated  Daily  Schedule 

"Unavailable"  in  context  of  the  beginning  and  ending  time  of  the  activity  under 
consideradon  at  the  moment  Event  requirements  are  numbers  indicating  the  number  of 
events  yet  to  be  completed  before  the  end  of  the  six  month  training  term  to  maintain  combat 
ready  status.  Event  currencies  are  also  numbers  which  are  the  days  remaining  before  going 
out  (rf  currency  in  a  particular  event  Operational  units  think  of  currency  as  a  date,  but 
numbers  were  more  easily  manipulated,  and  again,  humans  can  quickly  adapt  to  tire  altered 
represCTtation.  Preferences  are  normally  user-specified  character  strings;  the  system 
currently  uses  the  preference  attribute  to  terr^rorarily  preclude  the  scheduling  of 
unsuppoitable  pilots.  Hmes  are  represented  in  military  format  by  numbers  from  0  to  2400, 
although  tiiere  is  no  type  checking  to  flag  meaningless  values  such  as  1062  or  4000.  The 
availability  data  are  pain  of  times  indicating  the  start  and  stop  time  of  a  fiee  block  of 
unallocated  time  (or,  shifting  one  data  point  over,  the  stan  and  stop  of  a  slice  of  allocated 
time).  A  marupulation  of  tiiis  representation  is  a  list  of  durations  of  firee  time  and  allocated 
time  slioes  arranged  in  an  alternating  fashion.  The  duration  list  is  used  to  create  a  time  line 
chart  This  representation  is  acceptable  ftx’ graphing  purposes,  but  it  is  not  aesthetic  as  a 
primary  representation  because  of  the  error  induced  by  using  normal  numbers  as  time  (there 
are  only  60  minutes  in  an  htMu*).  Missions,  configuraticms,  and  ranges  all  are  represented 
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by  strings  of  their  commonly  used  abbreviations.  Explanations  may  be  user-specified,  but 
automated  ones  are  formed  by  appending  a  number  to  a  string.  (See  Hgure  9.) 

There  are  a  number  of  ways  to  access  or  reference  data,  as  described  earlier.  Atall 
times,  there  is  an  active  cell  in  a  selected  array  which  is  similar  to  the  address  pdnter  in 
assembly  language  programming.  As  discussed  in  the  last  ctuq>ter,  data  may  be  referenced 
by  its  relative  position  to  the  active  cell.  This  method  was  used  commonly  because  the 
visual  nature  of  the  display  maHa  relative  addressing  natural  and  understandable.  Of 
course,  the  spreadsheet  interface  names  each  data  cell  in  an  absolute  sense  as  well.  A  third 
alternative,  often  used  to  abstract  data  or  procedures,  is  the  assignment  of  a  user  defined 
name  to  data. 

Procedures.  The  primary  focus  of  the  aircrew  scheduling  prototype  was,  from  the 
beginning,  data  centered.  The  Excel-based  visual  programming  metiiodology  supported  a 
data  orientation  very  well  However,  Excel's  high  level  functions  and  relatively  clean 
separation  between  data  and  algorithms  allow  the  procedures  which  marupulate  the  data  to 
appear  very  powerful.  Three  hundred  lines  oi  code  inqrlemented  a  sqrhisticaled  heuristic 
scheduler  which  took  over  2000  lines  of  LISP  in  the  previous  prototype.  In  reality,  the 
macro  procedures  have  voy  little  to  do,  and  the  power  comes  fifom  die  high  level  functions 
and  continuous  display  and  update  inherent  in  Excel's  spreadsheet  interface. 

Some  algorithms  used  were  automatic  functions  whose  results  t^rpear  as  data. 
Availability  and  attribute  maximums  are  exan^les.  The  availability  calculation  results  in 
Tree"  or  "Unavailable,"  in  pan  depending  on  whether  or  not  the  activity  under 
consideration  tits  entirely  within  a  given  pilot's  free  time  block.  (See  Figures  3  and  8.) 
The  block  of  time  required  by  an  activity  (e.g.,  flyirig  a  mission)  is  defrned  by  its  stan  and 
stop  riffles.  Pilot  availability  data  are  stored  as  blocks  cS  free  time  (stan  and  stop  times)  in 
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the  linked  lists  attached  to  each  pilot  tuple  in  the  database.  Therefore,  its  simple  to  calculate 
availability  by  making  sure  the  activity  occurs  completely  within  unscheduled  time,  i.e., 
does  not  spill  inu>  a  previously  allocated  time  block.  The  odier  constraints  placed  <hi 
availability  arise  firom  Air  Force  reguladons  limiting  die  length  of  die  flying  day  and 
providing  crew  rest  The  availability  calculation  uses  last  landing  times  for  the  current  and 
previous  day  to  enforce  these  constraints. 

Most  algorithms  are  not  die  result  of  functions,  but  programs  known  in  Excel  lingo 
as  command  macros.  These  procedures  are  distinct  from  the  data;  they're  stOTed  in  a 
separate  file  and  are  manipulated  via  another  window.  Modularity  was  used  extensively. 
The  top  level  design  is  shown  in  Figure  10. 

The  scheduling  algorithm  to  find  an  a^iptopriate  pilot  uses  three  approaches  to 
heuristically  selea  a  pilot  if  one  is  needed.  If  a  pilot  has  been  suggested  by  the  user,  the 
algorithm  will  check  the  pilot  to  make  sure  no  constraints  are  violated  by  the  user  choice.  If 
constraints  are  violated,  the  system  defaults  to  automatically  finding  an  alternative,  ot  the 
user  may  direct  the  algorithm  to  halt  If  no  pilot  is  suggested,  the  routine  'find  pilot'  first 
checks  die  primity  Ust  for  a^licable  pilots  and  attempts  to  schedule  diem  in  order  of  their 
assigned  priority.  If  no  priority  pilot  can  be  scheduled,  the  algoridun  tries  to  find  a  pilot 
who  has  only  a  few  days  of  currency  remaining.  Why  is  currency  important?  Non-current 
pilots  require  instructor  pilots  to  regain  currency,  and  instructor  pilots  are  a  resource  for 
achieving  training  goals.  Therefore,  it  makes  sense  in  most  cases  to  assign  greater  priority 
to  flying  pilots  who  will  soon  go  out  of  currency.  IjOw"  curraicy  is  a  visible,  user- 
specified  parameter;  cunendy  it  is  set  at  7  days.  If  there  ate  no  pilots  who  may  be 
scheduled  because  ci  low  currency,  the  algorithm  looks  for  pilots  with  the  largest  number 
of  training  events  remaining.  The  primary  task  of  the  scheduler  is  to  provide  opportunities 
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1  Make  A  Schedule  | 

1 

Place  a  Pilot 

— 

1  Reset  Schedule  | 

1 

Remove  a  Pilot 

I  Print  Schedule 

I  Show  Schedule 


I  DNIFaPUot  I 


I  Free  a  DNBFed  Pilm 


Scheduling  Functions 


I  Show  Qualifications  | 
I^^^^ShowR^tnrcnMnKl 

I  ShovTcture^es  I 


I  Plot  Data 
I  Plot  Availability 


Pilot  Data  Functions 


Figure  10.  Excel  Aircrew  Scheduler  Top-level  Design 


fOT  required  training,  regardless  of  currency  status,  qualification,  OT  other  facttffs.  If  no 
pilot  can  be  found^^  using  these  three  approaches,  the  scheduler  reports  **NO  PILOT**. 
In  later  versions,  the  algoridim  will  backtrack  and  rearrange  the  schedule  to  fill  all  slots. 


^^hliis  may  occur  in  resouioe  rich  schedules. 
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Regardless  of  how  a  pilot  is  picked  by  the  system,  no  pilot  who  violates  constraints 
may  be  scheduled.  A  pilot  must  be  qualified,  current,  and  available  as  specified  by  the 
schedule.  A  pilot  who  is  not  current  or  who  is  in  mission  qualification  training  status  must 
fly  with  an  instructor  pilot  Qualification,  currency,  and  availability  are  pasted  into  the 
criteria  array  as  needed  by  die  algoridim;  the  criteria  inputs  serve  to  limit  die  selection  of 
pilots.  When  a  pilot  is  picked,  the  need  for  an  instructor  pilot  is  calculated.  There  are  three 
possible  results:  no  instructor  pilot  is  required,  an  instructor  pilot  is  required  and  there  is  at 
least  one  who  is  available  and  current  to  fly,  or  an  instructor  is  required,  but  none  are 
acceptable  because  of  availability  or  currency.  The  first  and  third  results  are  easily  handled 
by  scheduling  or  disallowing  scheduling.  The  second  case,  required  instructors  exist,  must 
be  handled  more  carefully  because  the  algcmthm  does  not  know  (remember)  the  status  ot 
scheduling  done  so  far  and  must  check.  If  the  schedule  slot  where  the  instructor  pilot  is 
needed  has  not  yet  been  filled,  the  algorithm  can  upgrade  the  required  qualification  fOT  that 
slot  and  fill  die  slot  below  widi  die  non-current  or  underqualified  pilot  currently  being 
considered.  However,  if  the  associated  instructor  pilot  slot  has  been  filled,  the  algorithm 
must  check  to  see  if  die  pilot  filling  it  is  an  instructor.  If  sOf  the  algoddun  will  place  the 
non-current  or  underqualified  pilot  Otherwise,  it  discards  the  non-current  or 
underqualified  pilot  just  as  if  no  acceptable  instructor  pilot  could  be  found,  and  selects 
another  pilot  for  consideration.  The  dual  interpretation  of  instructor  pilots  as  pilots  (jobs) 
and  resources  adds  to  the  conqilexity  of  the  problem  and  makes  handling  it  in  this 
procedure  the  preferred  way  of  scheduling. 

an  available  pilot  qualifies  for  a  missioa  and  is  supported  by  an  in^ructor  pilot  (if 
required),  the  algorithm  updates  the  pilot's  availability  arxl  places  him  on  the  schethife  with 
a  comment  explaining  the  chdce.  If  the  pilot  was  sdieduled  based  on  a  specified  priority, 
the  priority  list  is  commented  to  communicate  success  and  so  that  the  pilot  will  not  be 
selected  fitmi  the  list  again. 
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There  is  an  analogous  routine  for  removing  a  pilot  from  the  schedule.  Operations 
performed  include  clearing  the  pilot  slot  and  comment,  resetting  any  upgraded  qualification 
from  the  schedule,  freeing  the  allocated  time  frrom  the  pilot  availability  data,  and  clearing 
any  associated  comment  frrom  the  priority  list 

Routines  for  conqileting  or  resetting  an  entire  schedule  reuse  the  sniflller  routines. 
For  example,  to  automatically  make  a  schedule,  the  'mote  schedule*  routine  finds  the  last 
slot  on  the  schedule  and,  proceeding  upward,  fills  all  unfilled  slots  with  the  most 
appropriate  pilot  using  'find pilot.' 

There  is  a  routine  to  update  the  availability  oi  pilots  who  are  bu^  with  duties  not 
including  flying  (DNIF,  e.g..  medical,  ground  training,  a  staff  job,  etc.).  A  corresponding 
routine  for  fredng  DNlFed  inlots  is  also  implemented. 

Several  routines  have  been  written  to  display  different  views  of  the  rfata  One 
shows  die  schedule,  another  prints  the  schedule,  and  three  odiers  display  the  three 
projections  from  the  constdidated  database:  pilot  qualification,  events  remaining,  and 
currencies.  A  flexible  gnqihics  routine  allows  the  user  to  specify  up  to  four  attributes  frrom 
the  consolidated  database  to  produce  graphs  in  a  number  of  standard  formats.  (See  Figure 
8.)  Another  graphics  routine  produces  a  time  line  or  pilot  availability.  These  graphs  open 
as  windows  and  may  be  left  open,  although  their  continuous  recalculation  slows  execution. 

niots  mhy  be  added  or  deleted  widiout  distorting  the  data  structures  or  affecting  the 
algtnithms  in  any  way.  Similar  routines  could  be  written  to  add  or  delete  training  events, 
but  at  this  time,  that  process  is  manual 
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Data  updates  are  currently  done  using  serial  debriefing  and  data  propagation 
routines.  There  are  impcvtant  issues  yet  to  be  addressed  concerning  the  uncertainty  in  the 
database,  i.e.,  expected  versus  real  data.  These  issues  are  discussed  below. 

Additionally^  there  are  no  routines  or  data  stnictures  to  suppot  check  rides  or 
variable  cunency  values  (30  days  assumed  for  all  events)  in  this  demonstration  prototype. 

The  Interface.  On  the  Macintosh.  Excel's  interface  is  the  standard  pull  down  menus. 
The  aircrew  scheduler  prototype  retains  these  menus  and  adds  two  additional  menus. 
Schedule  and  Pilot.data.  All  user  fimctitms  described  are  available  from  mousing  cm  the 
different  menu  choices.  (See  Figure  10  fen*  functions  available  on  menus.) 

Using  the  Excel  Scheduler.  As  stated,  the  Excel  scheduler  has  been  developed  to 
provide  the  scheduling  officer  witii  real-time  data,  analysis,  and  flexible  scheduling 
supporL  In  practice,  the  scheduling  function  and  data  updates  will  be  used  most  because 
automated  scheduling  reduces  the  need  for  specific  data  and  analysis  is  needed 
infrequently.  Data  updates  include  initial  develqxnent  of  die  schedule,  insertion  of  a 
priority  list,  printing  the  final  schedule,  replying  to  the  priority  list  sender,  and  posting 
updates  to  the  database  resulting  from  flying  the  schedule.  For  the  puiposes  of  discussiem, 
it  is  assumed  that  the  Excel  prototype  and  suppOTting  software  exists  on  a  local  area 
network  (LAN)  of  Macintosh  Ilex  hosts  (a  LAN  of  different  hosts  is  possible). 

The  scheduling  officer  typically  schedules  two  weeks  in  advance.  For  each  day, 
therscheduling  officer  must  develop  a  partial  schedule  manually  (as  is  done  currently)  and 
insert  it  in  the  appropriate  format  in  die  schedule  data  file.  Schedule  development  on 
Excel's  tables  is  a  natural  analog  to  filling  out  the  current  schedule  tonplate  fonn.  The  level 
of  automation  suppent  provided  for  this  operation  is  similar  to  using  a  word  process^. 
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instead  of  papa  and  pencil  The  training  officer  or  other  supervisor  will  have  free  access  to 
pilot  data  and  is  expected  to  develt^  a  priority  list  in  an  Excel  data  file  to  be  sent 
electronically,  over  the  network,  to  the  scheduling  officer's  computer.  The  scheduling 
officer  pastes  the  priority  list  into  the  appropnsac  day’s  schedule  data  file  which  is  now 
ready  ftx-  scheduling. 

Ordinarily,  die  scheduling  officer  might  choose  to  let  the  system  generate  a  straw 
man  schedule  by  itself.  (SeeHgure9.)  The  straw  man  schedule  may  be  perfecdy 
acceptable,  or  the  scheduling  officer  may  choose  to  rearrange  it  or  try  unassigned  pilots  in 
place  of  the  prototype's  picks.  The  prototype’s  ‘remove  pilots'  and  ‘place  pilot'  routines 
support  the  scheduling  officer  by  updating  data  automadcally  and  constraint  checking 
changes.  The  scheduling  officer  may  also  use  the  consolidated  database  to  find  pilots 
meeting  certain  criteria.  Why  might  the  scheduling  t^cer  want  to  schedule  manually?  The 
scheduling  algorithm  used  by  the  prototype  is  a  kind  of  default  which  ordinarily  works 
well.  However,  the  scheduling  officer  may  have  addidtxial  informadon  which  impacts  the 
schedule  or  sittqrly  know  a  better  way  to  schedule.  The  Excel  prototype,  through 
sinuilation,  clearly  shows  the  scheduling  c^ce  what  it  is  doing  and  erqrlains  its  choices. 
This  visual  feedback  ma*^  die  program  more  understandable;  it  nu^  help  the  scheduling 
officer  discover  cases  which  are  not  supported  and  suggest  alternative  algtxithms.  Because 
the  algorithm  requires  less  than  300  lines  of  code,  the  scheduling  officer  may  even  choose 
to  implement  changes  himself. 

Oncethescheduleiscoinpleted,itmay  be  printed  out  direcdy  and  posted.  The 
priority  list,  having  been  commented  as  to  is  scheduled,  may  be  sent  back  to  die 
training  office  at  odier  supervisor.  Using  the  apprc^rriate  commercial  network  software, 
sending  files  across  die  network  equates  to  dragging  an  icon  into  a  folder. 
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When  pilots  return  fiom  flyiiig  the  schedule,  it  is  their  resprasibility  to  provide  data 
regarding  which  training  events  they  completed.  Normally,  completed  training  events 
differ  slightly  from  scheduled  ones.  The  current  prototype  does  not  support  anydiing  but 
sequential  updates  of  the  data  using  the  same  scheduling  data  file  as  the  scheduling 
algorithm  uses.  A  software  upgrade  is  planned  to  in^rove  the  debriefing  process.  The 
scheduling  officer  is  given  the  opportunity  to  review  a  pilot's  data  before  inserting  it  into 
the  database  (this  is  done  currently  in  practice).  An  improvement  on  this  manual  check 
would  be  an  automadc  constraint  check  using  knowledge  from  the  applicable  regulations, 
but  the  current  prototype  does  not  supp<m  such  a  check; 

When  analysis  is  required,  the  scheduling  prototype  allows  the  user  to  put  multiple 
graphs  on  the  screen  and  can  calculate  average  events  remaining  by  a  single  standard 
function.  These  analysis  tools  are  helpful  in  determining  die  ^pe  oi  missions  whidi  are 
needed  in  the  future  and  what  resources  are  required  to  fly  those  missicMis.  Pilots  may  be 
analyzed  in  relation  to  their  peers  as  to  their  training  progress;  deviations  of  data  may  be 
quic)dy  highlighted.  (3raphs  may  be  printed  out  ot  used  to  generate  slides  fOT  briefings. 

Constraints  on  Operations.  The  interface  allows  direct  editing  of  displayed  data,  so 
any  errors  may  be  corrected  easily.  However,  this  wide-open,  unprotected  interface  can 
lead  to  data  inconsistencies  and  wild  algraithms.  Excel  siqiports  dynamic  protection  of 
data,  but  the  current  prototype  uses  standard  programming  techniques,  rather  than  cell 
protection,  to  put  constraints  on  operations.  For  example,  the  'piiacepi/or' routine  will  not 
execute  unless  it  is  over  a  skx  on  the  schedule.  As  another  exanq>le,unDNIHng  a  pilot 
reports  an  error  if  die  requested  time  Mock  was  not  previously  allocated. 

Uncertainty  in  Schedule  Development.  A  current  development  task  is  the  handling 
of  uncertainty  in  pilot  data  during  different  times  of  the  schedule  life  cycle.  At  some  point. 
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generally  yesterday,  the  pilot  data  should  be  complete,  up-to-date,  and  true.  (This  is 
assuming  all  pilots  debriefed  on  dme.)  However,  schedules  are  made  for  two  weeks  in 
advance.  It  makes  mme  sense  to  schedule  based  on  an  expectation  oi  what  the  data  will  be 
for  the  day  the  schedule  is  to  be  flown.  Therefore,  future  scheduling  data  files  are  created 
with  the  database  updated  for  expected  events.  When  actual  data  are  obtained,  data 
inconsistencies  must  be  resolved.  Resolving  inconsistencies  is  not  difficult,  but  has  not  yet 
been  iiiq}lemented.  Cunently,  expected  data  and  its  repair  is  a  manual  process. 

Scalability.  The  current  prototype  database  has  3  events  and  14  pilots.  A  typical  A- 10 
squadron  may  have  30  pilots  and  must  track  at  least  17  different  events.  The  prototype 
generates  an  eight-slot  schedule  in  just  over  three  minutes  using  the  current  database.  With 
a  fiill  conqplement  of  pilots  and  events,  the  same  Excel  prototype  may  require  six  minutes  to 
schedule  eight  pilots.  This  execution  speed  is  considered  acceptable  for  A-10  sdieduling, 
but  may  be  too  slow  for  B-S2  aircrew  scheduling.  (B>52  pilots  alone  must  track  over  100 
events.)  The  Excel  prototype's  speed  is  limited  by  its  interpreted  macro  language  and 
display  updates.  Gmtinuous  display  is  very  helpful  fOT  determining  data  structures, 
relationships  between  them,  and  algtxithms  which  (iterate  on  them  to  produce  tiie  desired 
effects.  Therefore,  an  Excel-based  visual  methodology  may  be  useful  for  prototyping  a 
scheduling  system  even  if  the  system  must  ultimately  be  ported  and  conqnled  using  a  non¬ 
visual  language  to  enhance  execution  speed. 

Expanding  the  Network.  U^g  a  tabular  data  format  is  an  effective  way  of 
cominunicating  a  modoaie  amount  of  critical  infonnation.  A  computer  netwoik  with  user 
frigidly  file  transfor  allows  rapid  transmission  of  tabular  data  and  <^)ens  up  the  possibility 
of  automating  data  handling  and  analysis.  For  example,  a  unit-wide  LAN  might  include 
maintenance  as  well  as  aircrew  scheduling  and  provide  fm*  communication  between  the  two 
types  of  schedulers  as  well.  A  wider  area  netwoik  would  allow  fix’  better  communications 
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between  squadrcms  and  distant  support  (airfields,  air  refueling,  etc.)  Already,  some  of 
these  communication  links  ate  in  place,  but  automated  data  analysis  has  been  slow  in 
coming. 
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CHAPTER  6 

OTHER  APPLICATIONS  AND  IMPROVEMENTS  TO  EXCEL 

A  visual  programming  methodology  based  on  Excel's  spreadsheet  display  and 
program  animation  is  useful,  not  only  for  scheduling  i4)plications,  but  as  a  general 
programming  methodology.  Of  course,  there  are  a  number  of  improvements  which,  if 
integrated,  would  benefit  the  methodology:  formalizing  references,  adding  programming 
functionality,  and  increasing  support  for  abstractitm  in  a  number  of  ways. 

Other  Applications.  Using  Excel  and  the  visual  programing  methodology  described  in 
CHAPTER  3,  several  odier  {plications  were  developed  and  appear  in  the  APPENDIX. 
They  range  fiom  a  single  form  generator  based  on  functk»ial  programming  to  a  long 
distance  telephone  data  recorder  which  is  used  to  record  and  dqwsit  telephone  data  over  a 
network  to  an  analysis  center. 

A  sdution  to  the  eight  puzzle  described  by  (filsson  was  programmed  to 
demonstrate  the  utility  of  visually  explicit  data  structures.  The  eight  puzzle  is  a  matrix  with 
nine  positions,  eight  of  which  are  occupied  a  moveable  tile  widi  a  unique  number.  Tiles 

are  numbered  fiom  1  to  8  and  are  arranged  in  what  appears  to  be  random  order  in  the  initial 
state.  The  objective  is  to  arrange  tiles  in  increasing  order  around  the  periphery  of  the 
matrix,  ^filsson's  first  sdution  uses  hill  climbing.  The  hill  climbing  algorithm  has  been 
inq)lemented  in  Excd  as  a  short  program  sipoited  by  several  abstract  procedures.  The 
resulting  visual  program  dplays  the  matrix  of  the  eight  puzzle  in  a  concrete  representation. 
The  eight  puzzle  solution  appears  as  an  animated  program;  the  algoridun  used  is  quite  easy 


to  see. 
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Difficulties  Associated  with  Programming  in  Excel 

Spreadsheets  evolved  into  programming  languages  and  databases  because  of  user 
demand.  The  primary  users  of  Excel  and  other  spreadsheets  are  business  analysts,  not 
programmers.  Thereftxe,  the  Excel  programming  language  was  developed  for  ease  of  use 
and  power.  It  is  not  ftnmally  complete  in  the  sense  diat  LISP  or  Pascal  are  conqrlete.  Yet 
its  data  presentation  and  tqnesentation  capabilities  are  superior.  There  are  two  alternatives 
to  improving  Excel  programming  ctqrability.  The  first  is  to  patch  up  the  Excel  macro 
programming  language.  The  second  is  to  replace  it  with  a  standard  language  such  as 
Pascal. 

Data  References.  In  documentation  and  in  qreratitm.  Excel  often  confuses  the  location 
of  data  with  its  value.  This  is  because  Excel  converts  references  to  values  whenever  it 
deems  qrpropriate.  Excel  also  converts  types  to  other  types  when  it  needs  to,  rather  than 
giving  any  error  indicadon.  This  amiable  behaviOT  is  nearly  always  appropriate.  However, 
Excel  can  be  inconsistent  with  both  reference  and  type  conversion.  For  example,  cells 
ouiy  be  referenced  by  absdute  address  or  user-qrecified  name.  However,  die  standard 
command  fev  visiting  a  cell,  SELECT,  does  not  recognize  user-specified  names.  If  the 
noacro  programming  language  is  retained,  it  can  be  improved  by  allowing  any  naming 
convendtm  to  be  used  for  all  instructions. 

Prognumning  Fledbility.  Instead  of  enhancing  Excel's  macro  language,  it  would  be 
nice  to  be  able  to  use  a  standard  programming  language  with  Excel’s  spreadsheet  di^lay. 
An  already  complete  language  like  Pascal  or  Lisp  extended  to  allow  access  to  Excel's 


^^The  Excel  aiicrew  scheduler  praiocype  was  developed  using  Nficrosoft  Excel  veision  1.5  latlier  than  the 
new  version  2.2  currently  available.  Version  2.2  may  be  more  consistent  in  treating  reference  and  type 
convenkm. 
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spreadsheet  cells  would  blend  the  best  of  both  tools.  Program  animaticxi  could  be  retained 
by  having  the  Excel  portion  highlight  cells  as  they  are  accessed  or  changed,  still  updating 
changes  continuously.  A  less  ambitious  environment  would  simply  allow  Excel  code  to 
call  a  Pascal  routine  which  accesses  spreadsheet  data  and  transfers  control  back  to  Excel 
after  execution.  This  would  allow  more  sc^histicated  search  algorithms  to  run  on  visual 
data.  Excel  has  the  capability  to  exchange  data  with  an  external  file;  if  it  is  difficult  to  call 
an  external  routine  from  Excel  directly,  one  could  be  still  be  run  from  the  operating  system. 
A  third  alternative  is  m^lementation  of  a  spreadsheet  interface  to  Pascal  (not  a  trivial 
undertaking). 

A  spreadsheet  naturally  supports  data  structures  such  as  tables  and  two  dimensional 
arrays.  Queues  and  stacks  are  projections  of  two-dimensional  smictures  and  are,  therefore, 
supported  as  well.  Excel  fails  to  support  other  data  structures  quite  so  well  It  takes  a  little 
creativity  to  implement  a  liitked  list  or  a  tree  in  Excel  A  LISP  list  would  be  very  difficult  to 
represent.  However,  Excel's  spreadsheet  interface  strikes  a  good  balance  between  the 
appropriateness  ol  a  representation  and  the  ease  with  which  it  can  be  implemented  in  a 
prograia  It  would  be  very  difficult  to  program  a  better  way  of  displaying  a  tree  visually. 
Until  the  job  of  programming  a  better  visual  representation  becomes  trivial  it  is  sin^ler  to 
use  the  standard  interface  provided  by  a  spreadsheet 

Abstraction.  When  programming,  there  is  a  need  to  travel  in  both  directions  along  the 
spectrum  of  abstraction.  When  the  program  is  not  operating  conectly,  it  is  necessary  to 
look  closely  at  the  details.  Excel  supports  this  view  very  weU.  However,  to  address  large 
programming  problems,  one  has  to  create  abstraction  barriers  to  avoid  becoming 


^^It  is  interesting  to  note  that  visual  improvements  could  be  made  to  LISP  as  well  Consider  how  much 
easier  lists  would  be  to  read  if  different  font  sizes  were  used  for  pmentheses  and  elements  based  on  their 
relative  depth  in  the  listl 
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overwhelmed  by  the  details.  Excel,  like  other  programming  languages,  provides  naming  as 
a  procedural  and  data  abstraction  tool.  However,  in  Excel,  data  abstraction  is  not 
supported  to  the  extent  needed.  Using  LISP  or  even  Pascal,  it  is  possible  to  create  very 
complex  data  structures  useful  for  data  abstraction.  In  particular,  objects  in  the  object- 
oriented  paradigm  are  very  useful  for  modeling  complex,  real  world  objects.  Object- 
oriented  programming  is  not  supported  well  in  Excel  currently,  although  some  abstraction 
is  possible.  For  exait^le,  a  functional  result  like  availability  is  quite  a  cognitive  leap, 
considering  the  calculation  going  on  in  the  background.  However,  it  would  be  nice  to 
model  a  pilot  as  an  object  which  encapsulates  everything  in  a  pilot  tuple,  as  well  as 
procedures  for  updating  data  and  responding  to  requests  for  information.  That  is  not 
possible  using  Excel  because  there  is  nothing  to  prevent  access  to  cells.  However,  it  is 
easy  to  imagine  a  spreadsheet  which  can  support  the  enc2q)sulation  required  by  the  object- 
oriented  paradigra  The  requirements  are  that  cells  must  be  able  to  be  bound  tt^ether  ^ 
accessible  only  through  a  specified  interface.  Cells  may  be  bound  by  naming  them  as  an 
array.  By  arranging  object-arrays  physically  like  nodes  off  a  bus,  a  program  can  be  written 
to  ensure  that  only  a  single  interface  to  e^h  object  is  possible.  To  do  so,  the  program  must 
continually  check  to  make  sure  the  active  cell  is  either  on  the  bus  or  in  an  object 

Inheritance  and  dynamic  binding  are  also  elements  comnoonly  associated  with 
object-oriented  programming.  Inheritance  is  not  supported  by  Excel  and  would  require  a 
significant  effort  to  implement  by  programming.  Excel  currently  translates  types  so  well 
that  dynamic  binding  is  not  needed  for  primitive  types.  User-specified  types  (objects) 
would  require  additional  {nogramming. 

Originally,  Excel  version  1.5  was  used  to  develop  visual  programs.  Version  1.5 
failed  to  provide  enough  abstraction  support:  visual  abstraction.  Every  detail  of  the 
program  was  animated.  It  is  desirable  to  hide  details,  again  suppressing  them  when 
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abstraction  is  desired,  and  looking  at  them  when  details  become  important  There  are  three 
approaches  which  come  to  mind.  First,  a  small  amount  of  hidden  memory  which  act  as 
registers  in  a  microprocessor  might  be  included.  These  registers  would  take  the  f<xm  of 
additional  buffers  for  cc^y  and  paste  operations.  A  seccxid  alternative  is  to  use  higher  - 
level  procedures  which  combine  visit-cq)y  and  xasit-paste  (get  and  put  or  perhaps, 
get&put).  The  third  possibility  is  to  allow  the  programmer  to  specify  which  modules  are 
animated  The  newest  Excel  (version  2.2)  has  the  capability  to  turn  off  screen  updates 
during  macro  execution.  With  this  functionality,  the  programmer  now  has  control  over 
program  animation. 
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CHAPTER  7 
SUMMARY 

From  experience  in  develc^ing  die  Excel  aircrew  scheduler  prototype,  a  number  of 
conclusions  are  obvious.  Further  work  is  required  to  complete  the  prototype,  but  user 
input  is  required  to  attain  full  functionality. 

Conclusions 

Visual  environments  are  very  important  to  program  efficiency  and  program 
development  Being  able  to  see  data  and  data  structures  makes  them  explicit  and  concrete. 
Coupled  with  program  animation,  a  dynamic  display  of  changing  data,  visual 
structures  inqnove  the  debugging  process  and  support  verification  and  validation  of  the 
program.  Because  Excel  suppons  rearrangements  of  data  and  code  very  well, 
modifications  in  the  visual  environment  are  relatively  painless. 

A  spreadsheet  is  a  natural  interface  for  tabular  data.  The  two-dimensional  array  of 
the  spreadsheet  makes  maximum  use  of  the  surface  area  of  the  display  and  serves  as  a  good 
generic  interface  for  any  data  structure.  The  array  default  should  be  abandoned  only  when 
it  becomes  trivial  to  program  a  better  interface  for  a  specific  data  suiKtute. 

A  programming  language  with  a  spreadsheet  interface  is  very  useful  fw  heuristic 
scheduling  systems  but  w<xks  well  for  other  applications  as  well.  Because  spreadsheet 
data  structures  are  concrete,  a  visual  programming  language  based  on  one  is  very  useful  for 
prototyping  and  fa*  teaching  people  about  data  structures.  For  exaii^le,  an  assembly 
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language  programming  class  could  benefit  fiom  using  a  spreadsheet  to  model  a 
microprocessor  in  operation. 

When  programming,  there  is  a  need  to  work  near  both  ends  of  the  abstraction 
spectrum,  either  focusing  on  concrete  representations  or  viewing  large  parts  of  the  program 
abstractly.  The  visual  programming  language  suggested  in  CHAPTER  4  supports 
examining  details,  but  does  not  support  multi-level  flexibility  when  it  comes  to  program 
animation.  Improvements  made  to  Excel  version  2.2  allow  the  programmer  to  switch 
animation  on  and  off,  improving  the  visual  programming  process  considerably  through 
suppression  of  unwanted  detail.  Object-oriented  programming  might  be  useful  in  a  visual 
programming  environment,  but  is  probably  too  difficult  to  implement  using  Excel. 

♦ 

Future  W<»k 

The  current  aircrew  scheduling  algorithm  is  relatively  complete  and  flexible. 

However,  it  fails  in  the  cases  which  the  scheduling  officer  has  the  most  difficulty  with: 

♦ 

resource-rich  schedules.  When  there  are  too  few  pilots,  the  current  algorithm  schedules 
**NO  PILOT**  instead  d  checking  the  schedule  to  see  if  its  greedy  choices  might  be 
rearranged  to  complete  the  schedule.  Wcffk  is  continuing  to  fix  this  problem.’ 

Another  on-going  effort  addresses  the  generation  of  expected  future  data  and 
resolution  of  expected  future  data  with  actual  data.  No  research  is  required  to  address  this 
problem;  it  is  an  implementation  issue  only.  However,  research  is  required  to  develop  an 
expert  system  for  constraint  checking  pilot  debriefing  inputs. 

The  aircrew  scheduling  prototype  is  an  example  of  very  specific  application 
software  designed  to  solve  a  very  specific  problem.  Unfortunately,  specific  iq)pijcations 


require  knowledge  and  expertise  which  is  available  only  from  the  user.  Successful 
development  of  a  specific  application  requires  involving  the  user  up  front  Therefore,  the 
next  step  in  improving  the  current  aircrew  scheduling  prototype  is  to  ask  for  user  support  in 
testing  and  evaluation  of  the  software.  Without  user  feedback,  it  is  easy  to  design  software 
which  does  not  quite  solve  the  user's  problem. 
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APPENDIX  A 


The  following  paper  provides  a  system  description  of  die  1987  LISP  machine/KEE 
version  of  RADCs  aircrew  scheduler.  It  is  useful  as  background*  but  doesn't  indicate  the 
conqplexity  of  the  KEE  software. 
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Aircrew  Scheduling:  An 
Application  of  Expert  System 
Technology 


Capt  Doug  Dyer  and  Ms.  Sharon 
Walter 
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Griffiss  Air  Force  Base,  New  York 

ABSTRACT 

This  paper  describes  an  expen  system 
develop^  by  the  RADC  for  scheduling 
pilots  of  single  seat  aircraft  in  training 
sorties.  The  aircrew  scheduling  problem 
and  technologies  for  solving  it  are 
discussed. 

A  full  system  description  of  the  RADC 
aircrew  scheduler  is  presented,  along  with 
the  algorithms  that  it  uses.  Present  and 
plann^  developments  are  listed. 


Introduction 

The  Rome  Air  Development  Center  (RApQ 
is  a  large  Air  Force  labcnatray  responsible 
for  research  and  develq)ment  of  command, 
cmitrol,  communications  and  intelligence 
(C3I)  systems.  Artificial  intelligence 
research  is  pervasive  across  the  Center 
because  of  its  importance  to  command  and 
control  (C2)  systems.  In  1986,  RADC 
initiated  the  Air  Force  Innovative  Appli¬ 
cations  program,  an  in-house  effort 
designed  to  capture  the  expertise  of  Air 
Force  offices  in  deliverable,  "bite-sized" 
expen  systems.  Maj  Don  Henager  had 
served  as  a  squadrcm  aircrew  scheduler  and, 
under  the  program,  develop^  software  to 
automate  aircrew  scheduling  for  A- 10 
airoaft  RADCs  current  aircrew  scheduler 
is  an  expen  system  designed  to  assist  the 
squadron  scheduling  officer  of  a  single  seat 
hghter  squadron  in  his  daily  task  of 
assigning  pilots  to  a  limited  number  of 


sorties  in  order  to  meet  semi-annual  training 
requirements.  The  purpose  of  this  paper  is 
to  describe  the  aircrew  scheduling  problem 
and  RADCs  knowledge-based  software  for 
solving  it 


Thft  A-in  SqiiaHton  Aircrew  Scheduling 


Globally,  flying  of  the  A- 10  and  other  Air 
Force  airaraft  is  determined  by  die  resources 
available  and  the  training  requirements  of 
the  pilots.  Higher  headquarters  dictates  the 
total  number  of  flying  hours  for  a  given 
year,  based  on  funding  allocations.  Each 
unit,  or  wing,  tries  to  maximize  training 
within  the  flying  hours  constraint  Aircraft, 
maintenance  limits  the  number  of  aircraft 
available  and  specifies  tum-around  times. 
Munition  ranges  and  runway  times 
constrain  sortie  profiles. 

A  wing  scheduling  officer  negotiates  with 
and  resolves  conflicts  between  squadron 
scheduling  officers  and  is  responsible  for 
setting  the  type  and  mix  of  sorties  for  e^h 
day.  As  an  example,  for  a  given  day  a 
squadron  may  be  allotted  30  total  sonies 
consisting  of  18  weapons  delivery,  4  air-to- 
air,  and  8  instrument  sorties.  Each  sortie 
type  can  only  fill  certain  training 
requirements. 

The  squadron  scheduling  officer  is 
responsible  for  assigning  pilots  to  complete 
a  daily  schedule,  like  the  one  shown  in 
Figure  1.  The  scheduler  may  not  place 
pilots  in  sorties  arbitrarily;  pilot 
qualification,  currencies,  flight  training 
requirements,,  ground  training  requirements, 
and  availability  constrain  aircrew 
scheduling.  Qualification  is  based  on 
training  and  reflects  overall  experience. 
Qualification  levels  include  mission 
qualification  training,  missicm  ready,  two- 
ship  flight  leader,  four-stup  flis^t  leader, 
and  instructor  pilot  Currency  is  the  last 
date  of  completion  of  a  particular  training 
event  and  reflects  frequency  of  training 
For  example,  a  pilot  who  hasn't  landed  in 
30  days  is  not  current  for  landing  and  must 
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land  with  an  instructor  pilot  Flight  training 
^uirements  arc  specified  by  regulation  and 
include  many  separate  events  designed  to 
train  pilots  in  all  aspects  of  flying  the  A-10. 
Ground  training  events  must  be 
accomplished  before  flight  training.  Pilot 
availability  is  subject  to  duties  not  including 
flying  (DNIF)  and  leave.  Pilots  may  be 
plac^  on  DMF  status  for  many  reasons 
including  crew  rest,  illness  or  medical 
q>pointment  TDY,  staff  responsibilities,  or 
ground  training.  Under  &e  crew  rest 
concept. 
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Figure  1.  A  Daily  Schedule 


pilots  cannot  fly  for  longer  than  12  hours 
and  must  have  12  hours  of  crew  rest  ato 
flying.  Training  often  requires  more 
qualified  pilots  to  fly  with  less  qualified 
ones.  Two-  and  four-ship  flight  lexers  are 
always  required  for  A- 10s,  depending  on 
the  sortie.  Instructor  pilots  are  required  for 
qualification  upgrade  and  to  bring  pilots 
back  into  curre^.  Therefore,  scheduling 
a  less-qualified  pilot  to  fly  generally  implies 
a  constraint  that  a  mne-qualified  pilot  must 
also  be  available  to  fly. 

The  current  manual  method  of  daily  aircrew 
scheduling  is  tedious,  time  consuming  and 
error-prone.  The  squadron  scheduling 
officer  typically  builds  daily  schedules  two 
weeks  into  the  future  and  revises  them  as 


needed  when  the  scheduling  situation 
changes.  The  scheduler  often  receives  a 
priority  list  from  the  a  squadron  supervisor 
(the  supervisor  may  be  privy  to  special 
information,  such  as  leave  or  TDY  plans, 
for  example).  If  possible,  the  sch^uler 
will  place  pilots  from  the  pritnity  list  on  the 
schedule  or  may  negotiate  with  the 
supervisor  to  remove  pilots  from  the 
priority  list  The  scheduler  then  coinpletes 
the  schedule  by  essentially  adding  pilots  to 
the  priority  list  and  placing  them  on  the 
schedule.  The  scheduler  makes  every  at¬ 
tempt  to  maintain  currencies  and  provide 
oppmtunities  for  pilots  to  achieve  training 
events.  Currency  and  training  event  data 
are  provided  to  die  scheduler  in  the  form  of 
hard  copy  reports  from  a  centralized 
database  called  AFORMS.  Using  the 
reports,  the  scheduler  selects^  pilots  who 
w^  go  out  of  currency  soon  or  pilots  who 
are  getting  behind  in  training.  The 
scheduler  also  tries  to  fly  those  pilots  who 
are  attempting  to  upgrade  their  qualification 
level.  An  upgrade  to  instructor  pilot  is 
particularly  appealing  as  instructor  pUots  are 
a  valuable  resource  to  the  scheduler. 

Most  operations  done  manually  by  the 
squadron  scheduling  officer  are  analogous 
to  the  relational  database  operations  of  join, 
selection,  and  projection.  Selection  of 
pilots  bas^  on  currency  data,  training  event 
data  and  appearance  (xi  a  primity  list  could 
be  done  automatically  by  a  relational 
database  management  system.  However, 
additional  inference  is  required  to  take  into 
account  the  constraint  infrmnation  contained 
in  applicable  regulations  and  knowledge  of 
pilot  availability. 

The  traiiung  and  currency  information  from 
the  AFORMS  database  is  neither  updated 
nor  available  in  real-time.  Thoefore,  the 
scheduler  must  remember  recent 
information  to  work  effectively.  AFORMS 
stores  only  training  progress  and  currency 
data.  The  scheduler  must  keep  track  of  all 
other  constraints  which  affect  the 
scheduling  process.  In  addition,  for  pilots 
attempting  to  upgrade  or  return  to  flying 
status  from  a  staff  position,  AFORMS  fails 
to  reemd  training  events  accomplished  prior 
to  attairung  upgrade  status. 
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The  AFORMS  data  are  used  by  the  Training 
Officer,  Squadron  Conunanders,  and  others 
in  action  to  the  scheduler.  To  insure 
training  opportunities,  these  supervisory 
officers  cnder  corrective  actions  based  on 
the  AFORMS  data  which  can  be  incoo^lete 
and  slow  in  coining.  AFORMS  is  managed 
by  a  centralized  base  data  processing  center 
and  is  not  amenable  to  lo^  manipuladcm. 
Typically,  the  AFORMS  data  consists  of 
less  than  one  megabyte  of  information; 
neither  sttMrage  nor  pressing  requirements 
lie  outside  the  capability  of  a  standard  Air 
Force  microcomputer.  Updates  to  the 
database  are  acomiplished  using  hard  copy 
optical  scanner  sheets  filled  out  by  pilots  on 
sortie  completion.  Pilot  claims  are  checked 
for  feasibility  and  consistency  by  a  review 
board  prior  to  updating  the  AFORMS 
database. 

Although  the  scheduler  and  others  in  the 
flying  unit  benefit  fiom  the  data  provided  by 
die  ARDRMS  database,  there  is  a  need  for 
additional  data  tracking  and  faster  respcHise. 
In  addition,  data  reports  must  be  generated 
in  a  more  flexible  manner,  allowing 
different  users  to  obtain  sp^alized  reports 
in  a  timely  fashion.  There  is  no  reason,  for 
example,  that  briefing  charts  cannot  be 
generated  automatically  from  existing  data. 
Finally,  using  database  operations  and 
knowledge-based  heuristics,  the  aircrew 
scheduling  process  may  be  completely 
automated,  thus  relieving  the  squadron 
scheduling  officer  from  abwt  SO  pocrat  of 
the  scheduling  effort 

Scheduling  is  frequently  assigned  as  an 
additional  duty  in  conjunction  with  flying 
and  requires  50-60  hours  per  week, 
typically.  Squadron  aircrew  schedulers, 
after  we^  of  training,  serve  only  12  to  18 
months  in  tlw  job  before  "burnout”  occurs. 
The  rapid  turnover  of  pilots  in  a  fighter 
squadrm,  the  task  complexity,  and  the 
fir^uent  turnovCT  in  squadron  scheduling 
officers  in  the  Air  Force  makes  aircrew 
schedu^g  an  excellent  domain  in  which  to 
provide  compute  assistance. 


Scheduling  Technology 

Operations  research  techniques  have  been 
developed  to  solve  optimization  problems. 
Particulsaly,  linear  programming  algorithms 
such  as  the  simplex  method  result  in  an 
optimal  value  of  some  objective  funetkm  on 
solution.  A  scheduling  problem  may  be 
cast  as  an  optimization  problem;  the  sinq>lex 
method  has  been  successfully  applied  to 
scheduling  problems.  Although  aircrew 
scheduling  cmistraints  are  not  all  linear,  the 
problem  may  be  modelled  as  a  linear 
combination  and  linear  programming  may 
be  applied  to  solve  it  However,  there  are  at 
least  three  reasons  why  a  linear 
prograrruning  approach  is  not  the  best  one 
to  for  aircrew  scheduling. 

In  practice,  aircrew  schedules  change  many 
times  between  the  initial  draft  at^  flight 
dare.  Changes  are  r^uired  because  pilots 
berome  ill,  ft^  to  maintain  currency,  go  on 
TDY,  or  are  required  for  a  staff  duty.  Often 
the  scheduler  arrives  at  a  draft  using 
incomplete  data  and  must  revise  the 
schedule  once  the  actual  situation  becomes 
known.  When  a  scheduled  pilot  becomes 
unavailable  to  fly,  another  pilot  must  fill  the 
void  in  the  sch^ule.  The  substitute  pilot 
usually  must  be  as  qualified  as  the  original 
one.  Occasionally,  large  ptxtions  of  the 
schedule  must  be  rearranged  to  fill  the  vdd; 
however,  it’s  best  to  keep  changes  to  a 
minimum,  as  the  pilots  nrast  be  aware  of 
and  plan  for  the  mission  they  are  flying. 
The  scheduling  changes  that  become 
necessary  in  the  aircrew  scheduling  domain 
are  the  primary  reason  that  linear 
programming  techniques  are  not  suitable. 
Because  a  linear  programming  solution  is 
always  optimal,  a  void  in  the  aircrew 
schedule  can  cause  the  entire  solution  to 
change.  In  contrast,  when  done  noanually, 
the  schedule  can  stay  relatively  stable. 

Computational  efficiency  is  a  secondary 
reason  that  operations  research  methods  are 
less  useful  for  aircrew  scheduling.  Casting 
the  aircrew  scheduling  problem  as  a  linear 
problem  results  in  combinatorial  explosion. 
For  example,  given  30  pilots  to  fill  8  slots 
on  a  schedule,  there  are  nearly  236  billion 
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different  solutions,  neglecting  any 
constraints.  Linear  programming  tech¬ 
niques  must  be  temper^  with  heuristics  to 
limit  the  search  space  before  being  applied. 

Finally,  a  squadron  scheduling  officer  is 
generally  an  operational  pilot  with  little 
training  in  computer  science.  The  officer 
does  not  appreciate  software  which  returns 
recommendations  without  explanation,  as 
linear  progranimingalgnithms  do.  Instead, 
the  somvare  should  be  able  to  describe  why 
a  particular  pilot  was  chosen  ot  why  some 
other  pilot  wasn't  The  scheduling  officer 
wants  to  retain  control  and  understanding  of 
the  scheduling  process. 

Aircrew  scheduling  does  not  require  an 
optimal  solution,  only  a  good  one.  The 
algorithm  used  for  manu^  scheduling  is 
adequate  to  provide  training  opportunities 
for  sill  pilots.  These  two  facts  suggest  that 
a  knowledge-based  approach  is  more 
suitable  for  aircrew  sch^uling  than  linear 
programming.  A  knowledg  :-based 
approach  attempts  to  model  the  dgtnithm 
and  other  knowledge  used  by  the  human 
scheduler  and  to  buUd  an  scheduling  exj^ 
system  from  that  model.  The  resulting 
expert  system  should  solve  problems  in  the 
same  way  as  the  human  expert  does. 

Development  of  a  successful  expert  system 
frequently  depends  on  the  availability  of  a 
human  expert  and  iterative  knowledge 
engineering  to  mine  and  refine  the  human's 
expertise.  In  die  tactical  aircrew  scheduling 
domain,  the  constraints  governing  the 
scheduling  process  are  well-known  and 
published  in  regulations.  Therefore, 
although  RADCs  aircrew  scheduling  soft¬ 
ware  was  developed  by  a  human  domain 
expert,  it  could  have  be^  developed  using 
doomsentatioa  alone. 

Unlike  linear  programming,  a  knowledge- 
based  method  generates  a  robust  solution, 
just  as  a  human  scheduler  does.  For 
example,  small  changes  in  pilot  availability 
wiU  normally  result  in  small  changes  to  the 
schedule.  In  addition,  the  expert  system 
develop^  from  the  manual  scheduling 
model  avoids  searching  the  large  solution 
space.  Instead,  a  few  heuristics  guide  the 


search  to  a  nearly  optimal  solution  in  just  a 
few  seconds.  Another  advantage  of  a 
knowledge-based  approach  is  in  the 
presentation  and  explanation  of  information. 
Expert  systems  are  a  spin  off  from  artificial 
intelligence  research;  they  are  typically  rich 
in  friendly  man-machine  interface  features 
including  windows,  mouse  input,  and 
inference  chain  dumps.  With  a  little  extra 
programming,  the  iitference  chain  may  be 
used  as  the  basis  of  a  good  explanation 
capability,  as  it  has  been  in  the  RADC 
aircrew  scheduling  software.  Hie  level  of 
human  expertise  involved,  the  size  of  the 
knowledge  base,  the  need  fen:  an  intelligent 
search  mechanism,  and  the  large  numbCT  of 
disjoint  and  interrelated  constraints  posed 
by  the  domain  makes  it  appropriate  for 
expert  system  application. 

Object-oriented  programming  is  a 
programming  meth^ology  for  modelling 
real  world  objects.  The  objects  are 
represented  as  active  data  modules  which 
communicate  by  message  passing.  Classes 
of  objects  may  be  defined  and  objects  may 
be  defined  to  be  instances  of  a  class; 
instances  of  a  class  take  on  all  procedures 
and  default  data  values  df  the  cla^.  Hierar- 
chially  organized  classes  may  inherit  both 
data  and  procedures  from  classes  above. 
RADC  us^  objea-crioited  programming  in 
the  develqmient  of  it's  aircrew  scheduling 
prototyiw  because  the  methodology  allows 
abstraction  of  data,  rather  than  procedures, 
strictly  enforces  noodularity,  and  saves 
coding  through  inhedtance. 

A  Desciitrtion  of  the  RADC  Aircrew 
Scheduler 

The  aircrew  scheduling  expert  system  was 
developed  in-house  at  RADC  by  Major  Don 
Henager.  The  software  was  written  in  KEE 
(Knowledge  Engineering  Environment)  on 
a  Symbolics  3670  Lisp  I^hine.  The  KEE 
development  environment  is  an  expert 
system  shell  which  supports  object-miented 
programming  and  a  tran^arent  intoface  to 
the  Lisp  environment  of  the  Symbolics. 
The  ctni^ination  of  KEE  and  the  Symbolics 
Lisp  Machine  provide  a  powerful  envi¬ 
ronment  for  the  development  of  artificial 
intelligence  applications.  For  portability 
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reasons,  Coounon  Lisp  and  Common 
Windows  were  used;  extensions  to 
Common  Lisp  (other  than  Common 
Windows)  and  Zet^sp  were  avoided. 

The  interface  to  the  aircrew  scheduling 
software  is  through  a  series  of  windows. 
Pop-up  windows  are  used  to  display  menus 
of  available  operations.  Items  mi  thie  menus 
and  on  other  selected  objects  have  been 
programmed  as  mouse  "hot-spots”  and 
cause  the  software  to  react  iqipn^iriately  on 
mouse  input  A  mouse  documentation  line 
indicates  what  operations  will  occur  when 
one  of  the  three  mouse  buttons  are  pressed 
when  the  mouse  cursor  is  resting  on  a  hot¬ 
spot  These  features  make  the  interface 
very  much  a  "point-and-click"  affair. 
Keyboard  input  is  required  only  for 
inputting  items  such  as  a  pilot's  name  or  a 
new  date.  Mouse  input  is  even  used  to  edit 
some  items,  as  in  the  case  of  pilot 
availability. 

There  are  three  classes  of  scheduling 
operadoQs:  system  admiiustiation,  database, 
and  scheduling.  System  administration 
operations  allow  the  human  scheduler  to 
alter  characteristics  of  the  system  display 
and  to  make  changes  to  some  of  the 
scheduling  criteria  without  modifying  the 
software  code.  Those  operations  wili  not 
be  described  in  this  paper. 

Database  operations  are  used  to  store, 
display,  and  edit  all  information  pertinent  to 
the  scheduling  process.  The  scheduling 
algorithm  has  access  to  all  dau  and 
propagates  changes  to  the  database  as 
needed.  Like  the  AFORMS  database,  the 
aircrew  scheduling  software  stores  an 
identifying  key  (a  name,  in  this  case), 
qualification  level,  and  flying  hours  for  each 
pilot,  as  well  as  events  remaining  and 
currency  for  each  training  event  applicable 
to  the  pflot  In  addition,  the  system  stores 
pilot  availability,  flight  information,  the 
current  daily  sch^ule  (minus  the  pilots), 
and  the  primity  list  for  scheduling  pilots. 
These  four  data  items  are  required  inputs  to 
the  scheduling  system;  their  determination 
lies  outside  the  realm  ck  aircrew  scheduling. 
At  this  time,  they  must  be  manually  entoed 
by  the  squadrmi  scheduling  officer,  but  the 


system  has  been  built  for  easy  interfacing, 
should  the  data  become  available  on-line. 
As  the  current  aircrew  scheduling  software 
is  written  in  Lisp,  the  data  structures  used  to 
store  the  data  are  lists.  Most  data  is  stored 
in  a  single  large  database  and  is  associated 
with  the  appropriate  pilot  This  does  not 
present  a  i^blem  because  of  the  relaudvely 
small  amount  oi  information  required. 

Pilot  qualification  level,  events  remaining, 
and  currencies  can  be  displayed  in  a  tiU)ultf 
format,  just  as  they  are  in  the  current 
AFORMS  reports.  However,  because 
currencies  often  drive  the  scheduling 
process,  currency  information  can  also  be 
displayed  graphically  to  allow  the 
scheduling  officer  to  easily  see  who  should 
be  flown  rather  immediately.  The  graphical 
display  is  currently  discreet,  raSer  than 
analog;  only  two  types  of  pilots  are 
displayed:  those  who  will  go  out  of 
currency  within  a  week  and  those  who  have 
already  gone  out  of  currency.  Pilot 
availal^ty  is  also  di^layed  grtq>hically  and 
can  be  edited  graphically  using  the  mouse. 
Flight  bfcmnation,  the  imotity  list,  and  die 
daily  scli^ule  are  all  di^layt^  in  a  tabular 
form  to  retain  consistency  with  the  hard 
copy  analogs  currently  being  used  by  op¬ 
erational  squadrons. 

The  procedures  used  to  update  the  database 
are  tailored  for  the  particular  user  (most 
often  the  squadron  scheduling  officer).  On 
sortie  completitHi,  pilots  can  update  event 
and  currency  data  using  a  debriefing  rou¬ 
tine.  The  debriefing  routine  is  displayed  as 
a  window  similar  to  the  optical  scanning 
sheets  used  currently  and  can  be  filled  out 
using  the  mouse.  There  are  also  routines 
built  for  the  training  officer  to  edit  training 
or  currency  data.  For  the  scheduler, 
ordinary  eating, of  pilot  data  may  be 
accoo^lisbed  on  the  display  screens  as  all 
data  items  comprise  mouse  hot-spots. 
(Clicking  on  an  item  allows  it  to  be  edited 
The  flight  data,  priority  list,  and  schedule 
may  alw  be  edi^  in  this  fashion.  In  ad¬ 
dition,  there  are  a  several  routines  for 
handling  abnormal  conditions.  For 
example,  there  are  routine  >  for  altering  the 
data  items  tracked;  training  regulations  gov¬ 
erning  flight  training  change  relatively 


firequentiy.  When  pilots  enter  or  leave  the 
flying  squadron,  there  are  special  routines 
to  allocate  database  records  for  them,  enter 
them  into  training,  and  prorate  their  training 
requirements.  Prorating  a  pilot  reduces  the 
number  of  training  events  i^uired  to  match 
the  time  remaining  in  the  training  term. 
Routines  exist  for  loginning  a  new  training 
term  (six  months  in  duration)  or  zeroing  out 
requirements  for  a  particular  pilot  Zeroing 
a  pilot  out  is  necessary  fix'  pilots  who  leave 
flying  status  but  remain  in  the  squadron. 

Some  updating  procedures  are  used  to 
automatically  propagate  changes  caused  by 
the  scheduling  procedure.  For  example, 
once  a  pilot  has  been  scheduled,  the 
availability  display  shows  the  pilot  in 
"unavailable"  status. 

The  third  type  of  operation  available  on  the 
system  is  associated  with  the  scheduling 
process  itself,  rather  than  data.  Automatic 
scheduling  consists  of  matching  different 
types  of  sorties  with  pilots  of  varying 
qualifications  and  training  needs.  There  are 
two  different  algorithms  used  based  rni  the 
nanne  of  the  training  cycle.  During  the  first 
three  months  of  &e  training  term,  the 
training  requirements  of  the  pilots  have  no 
noticeable  trouble  areas  so  the  scheduling 
algorithm  can  be  simpler.  The  simple 
algorithm  ranks  sorties  in  increasing  orto 
of  slots  available  and  fills  them  with  the 
pilots  who  most  need  the  training,  taking 
into  account  any  requirements  fix  instructor 
pilots  or  flight  leadm  For  example,  given 
8  weapons  delivery,  2  air-to-air,  and  4 
instrument  sorties,  the  air-to-air  sorties 
would  be  filled  ^t,  followed  by  the 
instrument  sorties,  and,  finally,  pilots 
would  be  assigned  to  weapons  delivery 
sorties.  The  idea  behind  this  simple 
algtxithm  is  that  air-to-air  sorties  are  most 
fxecious,  as  there  are  least  of  them.  This  is 
very  simplistic  reasoning,  as  the  next  day 
may  include  12  air-to-  air  sorties.  However, 
during  the  first  three  months,  the  algcxithm 
works  well. 

During  the  second  three  months  of  the 
training  term,  the  scheduling  algorithm 
evaluates  the  current  status  of  pilots  and  of 
the  squadron  as  a  whole  to  determine 


scheduling  pritxities.  If  any  individual  pilot 
or  the  squadron  average  falls  behind  in  an 
event,  diat  event  becon^  a  high  ^ority  for 
the  pilot  or  the  squadron,  respectively.  For 
example,  if  a  pilot  has  50  percent  of  his 
weapons  delivery  events  remaining  and 
(xily  16  percent  of  the  training  time  remains, 
we^xms  delivery  becomes  a  high  pricxity 
event  for  that  pilot  Alternatively,  if  the 
squadron  has  20  percent  of  its  weapons 
delivery  requirements  remaining  with  16 
percent  of  the  training  time  remaining, 
weapons  delivery  events  would  become  a 
priority  for  all  pilots.  The  nwre  complex 
scheduling  algorithm  ranks  sorties  ac¬ 
cording  to  their  relative  ability  to  fill  the 
priority  training  requirements,  rather  than 
on  the  relative  number  of  slots  available. 
Those  sorites  that  can  fill  the  highest 
number  of  priority  requirements  will  be 
filled  first.  Using  this  ranking,  slots  are 
filled  as  with  the  simpler  scheduling 
algorithm,  using  pilots  who  require  the 
training  the  most 

If  the  distribution  of  future  sorties  were 
known,  the  scheduling  process  would  be 
much  simpler.  However,  the  distribution  of 
future  sorties  is  not  known.  Indeed,  if  the 
squadron  requires  additional  sorties  of  one 
type,  the  distribution  may  shift  to 
accommodate '  the  need.  However,  the 
distribution  is  also  influenced  and 
constrained  by  other  facuxs;  therefore,  the 
flexible  algtxithms  above  are  needed.  The 
algorithms  described  are  based  on  the 
experience  and  knowledge  of  an  expert 
hunoan  aircrew  scheduler  and  have  proven 
to  give  robust,  acceptable  solutions  in  near 
realtime. 

After  ranking  the  sorties,  the  aircrew 
scheduling  system  assigns  pilots  to  slots.  If 
possible,  all  pilots  on  the  priori^  list  are 
scheduled,  'ne  raticmale  for  doing  this  is 
that  the  squadron  supervisor  shoitid  have 
the  same  level  of  control  over  the  srrftware 
scheduling  system  as  he  does  over  the 
human  scheduler.  Currencies  are  the  next 
criteria,  and  training  needs  are  considered 
last.  The  criteria  order  may  be  altered 
without  programming  to  match  the 
scheduling  philosophy  of  the  particular 
squadron. 
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The  actual  scheduling  procedure  is 
accomplished  using  rules  as  a  means  of 
disqualifying  pilots  from  sorties.  The 
sample  rule  shown  below  would  disqualify 
a  pilot  from  a  sortie  for  which  he  is  not 
available: 

(IF 

(AND 

(THE  TOT  OF  7SORTIE  IS  7START) 

(THE  LT  OF  7SORTIE  IS  TEND) 

(NOT  (AVAILABLE-PILOT  7 

PILOT  7START  TEND) 
(INVALID-SOLUTION  7PILOT 
7SORTIE) 

A  pilot  must  pass  through  the  endie  gaundet 
of  disqualiflcation  rules  before  being 
assigned  to  the  sortie.  As  the  system 
progresses  through  the  daily  schedule,  it 
builds  a  list  of  unused  partial  solutions.  In 
the  course  of  assigning  pilots  to  sorties,  the 
system  may  arrive  at  a  point  where  the 
remaining  sorties  cannot  be  assigned. 
Instead  of  backtracking  to  the  starting  point, 
the  algorithm  will  look  for  alternative 
solutions  on  the  unused  partial  solution  list 

Once  an  aircrew  schedule  has  been 
generated,  the  scheduling  officer  can  click 
on  any  pilot  and  receive  an  explanation  as  to 
why  the  pilot  was  selected  (pilot  names  are 
also  mouse  hot-spots).  This  feature  is  ex¬ 
tremely  important  because  scheduling 
officer  often  need  to  be  able  to  explain  their 
choices  to  scheduled  pilots  and  supervisors. 
Moreover,  schedule  lines  may  be  added  or 
deleted  on  the  display  screen  to  reflect,  for 
example,  when  an  scheduled  aircraft  must 
undergo  maintenance  instead  of  flying. 

The  squadron  scheduling  officer  may  use 
the  aircrew  scheduling  system  in  a  s^ni- 
automated  mode  as  w^  For  example,  the 
officer  may  change  a  particular  pilot  on  a 
generated  schedule.  The  system  will  au¬ 
tomatically  check  the  candidate  i^oc  and  the 
entire  sch^ule  for  constraint  violation.  If 
the  new  pilot  violates  constraints,  the 
system  will  repmt  the  violations,  but  it  will 
not  rudely  renoove  the  pilot  The  scheduling 
officer  can  use  the  system  in  this  way  to 
manually  generate  a  schedule,  if  desired.  If 


two  pilots  appear  on  the  schedule,  the 
scheduling  officer  can  cause  them  to  swap 
positions.  In  addition,  there  are  specif 
database  operations  available  on  the 
scheduling  window.  With  these  operations, 
the  system  can  find  all  pilots  who  satisfy  a 
given  criterion.  For  example,  all  two-ship 
flight  leaders  who  are  current  in  weapons 
delivery  may  be  displayed.  Also,  the 
priority  list  may  be  (ti^layed  and  edited 

Future  Development 

The  RADC  aircrew  scheduler  prototype  has 
been  demonstrated  to  many  hi^-level  DOD 
members  and  has  been  enthusiastically 
reviewed.  However,  its  current  hardware 
and  software  requirements  are  too  great  for 
an  operational  unit  to  afford.  Parallel 
efforts  are  ongoing  at  RADC  to  transport 
the  functionality  of  the  system  to  an  Intel 
80386-based  personal  computer  and  an  /tir 
Force-standard  Zenith  Z-248.  Those 
develi^ments  are  expected  to  be  complete 
by  1990.  The  software  will  be  modified  to 
include  reasons  for  non-availability,  such  as 
leave  and  ID  Y. 

The  artificial  intelligence  technology 
required  for  well-defined  scheduling  is 
generic  enough  to  be  ^plied  to  many  other 
types  of  sch^uling  prc^lems  that  exits  in 
the  Air  Force  and  other  DOD  services.  For 
example,  aircraft  maintenance  and  air 
refueling  schedules  can  be  auuxnated  using 
knowled^-based  techniques.  These  types 
of  scheduling  problems  are  also  being 
considered  by  the  Air  Force  Innovative 
Applications  irogram.  It  is  hop^  that  the 
expertise  gained  from  treating  these 
problems  may  be  formalized  into  a  generic 
"language"  for  scheduling. 

The  data  which  serve  as  inputs  to  the 
aircrew  scheduling  problem  seem  to  be 
suj^lied  and  used  in  a  distributed  fashion. 
Neither  proces^g  nor  storage  of  the  data 
requires  anything  more  powerful  than  an 
80286-bas«d  personal  conqiuter.  Local 
storage  of  data  would  enable  less 
cmistricted  data  flow  and  greater  flexibility 
in  the  use  of  the  data.  Mmeover,  diffnent 
automated  tods  for  scheduling  and  database 
operations  are  anticipated.  For  example. 
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pilot  claims  could  be  screened  automadcally 
for  feasibility  and  consistency  before  being 
reviewed  manually  and  inserted  into  the 
database.  TherefcHe,  the  ideal  architecture 
for  scheduling  in  an  operaticxial  squadron  is 
probably  a  local-area  network  (LAN)  of 
personal  computers.  RADC  is  currently 
developing  a  LAN  test  bed  for  different 
schedulers  to  operate  in  a  cooperating 
fashion. 
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APPENDIX  B 


The  following  paipex  discusses  initial  ideas  related  to  a  visual  programming 
methodology  using  I^crosoft  Excel  and  describes  a  currency-driven  aircrew  sch^uler 
developed  in  tlw  summer  1989  at  RADC  The  current  Excel  prototype  uses  two 
additional  scheduling  drivers  to  arrive  at  better  schedules  that  expuid  solutions  to  more  of 
the  feasible  space,  in  addition  to  providing  many  mcMte  user  fiin^ons.  However,  die 
currency-driven  scheduler  demonstrates  tow  quickly  a  simple  scheduler  may  be  built  using 
the  visual  programming  methodology  based  on  Microsoft  &cel.  The  currency-driven 
scheduler  required  only  120  lines  of  code 


80 
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The  difficulty  with  most  expen  system  programming  problems  is  that  not  only  is  building 
an  ai^lication  coo^licated  in  itself,  but  also  the  con^lexity  of  the  ctxnputer  system 
discourages  the  opmtional  user,  who  is  usually  a  novice  programmer.  What  is  needed  is  a 
simple  programming  system  so  Ae  domain  expert  doesn’t  have  to  be  a  computer  expert 
Althou^  high-performance  architectures  allow  for  greater  flexibility  and  sp^,  their 
-complexity  adds  undesirable  oveibead  to  the  development  effort 

Some  of  the  recent  attempts  to  siri^lify  software  development  have  been  expert  system 
shells,  objea-oriented  programming,  gri^)hical  interfaces,  and  fourth-generation 
programming  languages.  Sirr^le  expert  system  shells  do  little  more  tluui  formalize  rule 
representation  and  restria  ordmaiy  prognuxmnng  languages  to  sequential  if-then-dse 
structures.  More  powerful  shells  provide  additiraal  knowledge  rqrresentation  and 
inference  alternatives  at  the  e}q)ense  of  increased  conq)lexity.  The  object-oriented 
programming  approach  promc^  the  useful  attributes  of  abstraction  on  data  objects  and 
modularity  b^een  objects,  but  this  paradigm  is  accompanied  by  new  languages 
(Smalltalk)  or  language  extensions  (C-h-)  thitt  ate  non-mvial  and  somewhat  counter¬ 
intuitive  to  programmers  traditionally  trained  on  procedural  languages. 

Graphical  interfaces  are  more  successful  at  conveying  information  than  text,  and  they  treat 
the  coaq)uter’s  ouq)ut  limitation  very  well  from  a  user’s  standpoint.  Unfortunately,  getting 
grqrhical  ouptut  requites  ccmiplex  programming.  Fbuitii-generation  programming 
languages  treat  powerful  procedmes  on  complioued  data  structures  as  language  prinutives, 
reducing  conqtlexity  by  abstraction.  A  fburtfa-genetation  language  endowed  with  graphics 
capability  allows  the  programmer  to  utilize  the  tools  ptovuU  by  the  higher-level  language 
to  get  output  in  the  desired  form,  witiiout  the  need  for  e3q)licit  prognmming.  Oneexatrple 
of  this  Id^  of  tool  is  a  debugger,  which  displays  variable  values  while  die  programmer 
executes  a  ptogranL  This  type  of  continuous  visual  display  has  a  logical  liimt  that  has  been 
known  to  business  users  for  years  as  a  spreadsheet  A  spreadsheet  consists  of  a  large,  two- 
dimensionai  array  of  cells  which  may  contain  constants  or  variables  (i.e.,  the  results  of  a 
framtila).  These  cells  are  continuously  calculated  and  displayed,  an  effective  way  of 
.  treating  the  computer's  shyness  about  ouqiut  and  avouting  complex  graphics  programming. 
Althou^  spreadmeets  began  life  as  "whtt-iT  tools  for  business  users,  they  quickly 
expanded  into  database  management  systems  and  added  the  flexibility  of  programming 
through  macros.  Currait  qirnKlsheets,  like  Microsoft  Exc^  feature  powerful  functions 
and  utilities,  placing  them  in  the  category  of  fourth-generation  langua^ 

Althou^  qxeadsheets  are  not  often  diought  oi  as  programming  language^  qneadsheets 
are  appropriate  for  solving  some  of  the  pr^lems  of  interest  to  tte  Rome  Air  Development 
Center  (RADQ.  In  particular,  well-defined,  constraint-based  scheduling  problems  (among 
others)  are  easy  to  solve  using  a  spreadsheet  As  part  of  an  aircrew  sch^der 
devek^naent  RADC  has  develop^  an  iiuiovative  programming  methodology  based  on  the 
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use  of  a  spreadsheet  as  a  visual  prograimning  language.  Not  all  of  the  desirable  properties 
of  the  visual  piDgramming  language  we  envision  are  embodied  in  current  spreadsheets. 
However,  for  many  problems,  the  advantages  of  using  a  visual  programming  langiuge  far 
outweigh  the  shortcomings  of  current  spreadsheets.  We  consider  visual  programming 
methoddogies  to  be  important  in  reducing  inogramming  complexity,  e^iiecially  for  novice 
programmers. 

We  devote  the  first  portion  of  diis  paper  to  the  advantages  oi  visual  programming 
languages  over  conventional  higher*<»dered  languages  such  as  Pas^  C,  or  Ada,  and  then 
adrnit  scnne  disadvantages.  The  second  portitHi  d  ^  prater  is  a  system  description  of  the 
particular  application  of  interest,  a  daily  aircrew  scheduler  which  assigns  pilds  to  training 
missions.  The  scheduler  is  a  prototype  expert  system  which  was  portixl  firom  a  LISP 
machine  in  the  KEE  3.1  environment  The  new  prototype  currently  does  not  support  die 
entire  functionality  d  the  KEE  version,  but  has  t^n  ir^lemented  by  novice  programmers 
in  only  three  wee^  and  a  few  hundred  lines  of  code.  This  represents  a  code  reduction  of 
at  least  one  order  oi  magnitude  for  a  complete  port 

Advantages  of  a  Visual  Programming  Language  Over  Conventional  Languages 

We  have  found  this  portion  difficult  to  write,  as  many  of  the  advantages  are  subtle  and  they 
range  frcmi  matters  of  convenience  to  cognition.  In  the  discussion  that  follows,  we  do  not 
differentiate  much  bdween  what  we  call  a  visual  programming  language  and  our  current 
spreadsheet,  Microstrft  Excel,  except  fd  Excel  attributes  whit^  are  cl^y  not  associated 
with  the  visual  nature  of  the  tooL 

When  developing  a  program  using  Pascal  or  C  die  programmer  must  iteratively  determine 
die  need  for  a  variable  in  the  program  and  allooue  it  in  a  type  declaratkm.  This  is  because 
these  languages  effidendy  gu^  memory  resources.  Each  variable  type  is  allocated  die 
least  amount  of  memory  that  it  needs,  so  the  particular  type  is  important  and  must  be 
declared  by  the  programmer.  Swapping  from  the  program  to  the  declaratimis  block  is 
distracting  to  programmers,  but  usefid  fdointime  effidency.  Languages  like  LISP  relax 
the  need  for  strong  ty^g  and  dyn^ca^y  allocate  memory.  Spreadsheets  go  even 
furdier,  by  pre-allocating  memory  into  a  two^limensional  array  (most  convenient  for  visual 
display  on  a  twoKlirr^r.sionai  screen).  Visual  programming  languages  also  allow  any  data 
typed  even  a  fdmuia  (functional  procedure)  to  occupy  a  data  cell.  Furthermore,  cells 
already  have  their  own  names,  Le.,  Al,  J45,  etc.  Moreover,  assigning  values  to  data 
locations  is  at  least  as  sirr^le  as  fd  convention^  languages. 

Also  when  using  Pascal  dC  if  output  is  desired,  output  must  be  programmed.  A 
program  that  provides  no  output  has  no  value,  yet  the  programmer  must  go  to  special 
lengths  to  obtain  outyut  Visual  programming  langu^es  supply  continuous  outyut  in  a 
two-dimensional  window  stream  without  programming,  which  is  clearly  a  mde  sensible 
approach  for  data-centeted  problems.  When  executing  a  conventional  ^gram,  medal 
di^lay  code  (d  a  debugger)  is  required  to  discover  vtdues  of  pertinent  variables  fd 
program  verification  d  digging.  The  continuous  calculation  and  diq^  trf  a  visual 
programming  language  nudtes  this  extra  code  unnecessary. 

Iidn  a  cognitive  stan^wint,  visual  programming  languages  are  siq)erid.  The  continuous 
di^lay  of  data  relieves  ptograrrmen  frm  having  to  remember  variable  names  and 
meanings  and  also  provides  additional  (human)  memory  association  (opportunities.  By 
default,  pte-defined  names  for  data  cells  are  displayed  and  can  be  mentally  derived  by 
projection  (e.g.,  Al  is  the  ceil  in  column  A  and  row  1).  If  the  meaning  oi  the  data  cell 
needs  commenting,  tite  comment  may  (xxupy  an  adjac^t  cell  Furthamore,  the  cell  can  be 
referred  to  with  a  user-defined  name,  just  as  variables  in  a  conventional  programming 
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language  are.  User-defined  names  act  as  aliases  for  absolute  addresses  (e.g.,Al).  The 
two-dimensional  display  also  has  a  more  subtle  advantage:  data  exists  in  plsnar  space. 

That  is,  each  cell  is  in  a  definite  location  reladve  to  other  cells.  A  programmer  knows  a  cell 
both  from  its  name  and  from  its  location  on  the  display.  Hnally,  ^ta  structures  in 
conventional  programming  languages  are  invisible,  abstract,  arid  seemingly  unrelated  to 
one  another  in  space;  programmers  often  draw  individual  data  structures  to  conceptualize 
them  (fen*  example,  li^ed  lists).  Bodi  of  these  issues  are  addressed  by  visual 
programming  languages.  Although  limited  by  current  spreadsheets  to  rectangular  arrays, 
the  data  structures  of  a  visual  programnoing  language  are  displayed  by  the  language-  lliey 
are  quite  concrete.  Fuithenmne,  because  of  the  two^limensional  space,  data  structures  are 
phyacaUy  related  as  well  Conceptually  related  data  may  be  placed  physically  close 
together,  if  desired.  The  physical  display  of  data  also  works  for  the  display  of  the  program 
source  code.  Typical  conventional  languages  are  edited  essentially  as  linear  strings. 
Despite  structure  programming,  one  pmedure  follows  another.  This  is  not  at  aU  tme  for 
the  two-dimension^  di^lay  area  of  a  visual  programming  language.  Although  each 
procedure  (macro)  occu^es  a  linear  column  of  cells,  a  second  procedure  can  be  platted 
north,  east,  south,  or  west  of  the  first  By  using  a  two-dimensional  programming  area,  a 
higher  degree  of  structure  is  added,  and  the  advantages  of  structured  programming  are 
amplified  as  a  result 

Visual  progpmnmg  languages  siqiport  data  abstraction.  A  cell  may  be  tiata  or  a  fimctional 
proc^ure,  in  which  case  the  result  is  continuously  calculated  and  dkplayed  as  data.  Each 
cell  is  siinilar  to  an  object  in  the  object-oriented  paradi^  although  tte  interface  is  rather 
open  and  only  (Mie  "mediod"  may  be  stored  inside.  This  is  a  limitation  of  the  currently 
available  spreadsheets;  new  "tiuee-dirttensional"  spreadsheets  might  be  better  as  visual 
implementations  of  object-oriented  languages. 

As  a  graeral  rule,  languages  should  be  extensible.  Current  spreadsheets  suppon 
extensibility  of  their  fourth-generation  cap>abilities  by  supporting  user-defined  functions.  In 
Excel,  these  are  called  "functional  macros"  and  differ  ccmceptually  from  the  "command 
macros"  which  ate  executable  programs.  Functional  macros  are  applicative,  rather  than 
proceduraL 

In  terms  of  artificial  intelligence  psogramming  (and  many  others  domains  as  well),  it  is 
often  difficult  for  die  knowledge  engineer  to  know  what  data  is  relevant  and  what 
relationships  exist  between  different  data  sets.  Using  a  visual  programming  language 
encourages  the  programrim  to  plpce  date  in  displayed  date  structures  before  writing 
procedures.  The  visual  display  date  structures  seems  to  help  in  defining  what 
procedures  are  possible  and  determining  the  relationships  between  data.  The  idea  of 
throwing  lots  of  data  onto  the  compniter  screen  without  much  regard  for  its  relevancy  is 
similar  to  the  approach  chosen  by  many  neural  net  programmers.  It  is  not  costly  to  either 
typie  of  prograrnmer  to  use  this  approach,  and  the  data  that  turns  out  to  be  unimportant  can 
be  thro^  away  later. 

Because  data  structures  in  spreadsheets  are  two  dimensional  arrays,  relative  addressing  is 
used  much  mcae  fiequendy  to  access  date  than  for  other  languages.  For  example,  it’s 
common  to  go  “(Miecdumn  over  and  two  rows  down.”  This  characteristic  is  noore  useful 
dian  ab<"^!ute  ”by  name”  addressing  when  the  data  stnictute  must  be  modified,  because  not 
every  cell  has  a  user-defined  alias.  All  current  ^preads^ts  recognize  the  need  for  (hua 
array  changes;  relative  addressing  is  the  default  operating  mode.  Data  structures  may  be  cut 
and  pasted,  and  the  system  updates  references  to  them  automatically. 

(Command  macros,  the  programs  of  spreadsheets,  typically  access  data  on  a  spreadsheet  by 
“visiting”  the  cell  where  the  date  is  located.  The  macro  language  can  use  the  date  to  make 
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calculations  and  copy  the  results  into  another  visited  cell.  This  is  exacdy  what  happens  in 
any  programining  langua^,  but  with  a  spread^eet,  the  process  is  displayed  visually, 
ra^er  than  being  kept  invisible.  For  example,  Excel’s  active  cell  is  displayed  as  a  colored 
outline.  As  a  macro  executes,  the  active  cell  indicator  moves  around  on  the  screen. 
E>ebugging  is  much  sin^ler  when  every  step  of  a  pn^ram’s  process  is  displayoL  With  a 
visual  programming  language,  there  is  never  any  need  to  write  test  procedures.  In  the 
particular  case  of  &cel,  macros  may  be  ^gle-stepped  which  is  a  good  debugging  feature. 

Command  macros  can  be  executed  by  other  macros.  This  feature  encourages  procedural 
abstraction  and  code  modularity.  Althou^  programs  like  C  and  Pascal  also  have  this 
feature,  the  two-dimensional  placement  opportunities  and  loose  data  typing  of  a  spreadsheet 
encourage  programmers  to  bi^  up  the  program  properly. 

Spreadsheets  have  many  primitive  functions  which  are  really  sq}histicatBd  procedures, 
qualifying  them  as  fouidi-generation  tools.  Among  these  primitives  are  madiematical, 
statistical,  database  and  dt^  functions.  In  addition,  advanced  graphing  utilities  are 
included.  Excel  features  custom  menus  and  dialog  boxes,  making  user-interfaces  easy  to 
construct  These  features  are  not  unique  to  visual  programming  languages,  but  they  are  a 
useful  aspect  of  all  spreadsheet  systems. 


Visual  programming  languages  have  an  inhosnt  processing  overhead  associated  with 
display  and  oxitinuous  calculation  of  formulas  in  cells.  However,  it  is  reasonable  to  trade 
runtime  execution  speed  for  programming  benefits  in  an  era  of  fasta  hardware.  Also,  in 
our  e^qperience,  a  visual  prograimning  language  is  useful  as  a  prototyping  aid,  even  if  the 
eventual  product  will  be  cod^  in  an  efficient  ^  iguage  such  as  C  We  initially  tried  to  ptm 
the  KEE  aircrew  scheduler  directly  into  C  cock,  but  development  was  slow  b^use 
relationships  between  data  were  unclear.  Now  that  a  sprea^eet  prototype  exists,  we  feel 
confident  that  a  C  version  of  the  prototype  could  be  quickly  coded. 

For  many  {xoblems,  a  two-diixwnsional  array  is  not  the  best  data  structure  to  use.  The  idea 
of  a  visurd  programming  language  doesn’t  i^lude  other  data  structures,  but  current 
spre^heets  t^  to  discourage  theta  For  example,  current  spreadsh^  treat  single  cells 
(variables)  or  arrays  as  default  data  structures.  A  linked  list  is  not  terribly  difikxilt  to 
implement,  but  a  tree  structure  mig)it  be.  New  three-dimensional  qneadsheets  certainly 
offer  other  possibilities. 

Designed  as  business  tools,  current  spreadsheets  are  not  as  rigorous  as  a  visual 
programming  langiuges  should  be.  For  example,  there  should  be  a  clear  distincticm 
between  data  meaning,  value,  and  address.  current  Excel  versiem  frequently  uses 
“reference”  to  mean  eidier  address  or  value.  In  addition,  ctmtrol  and  branching  constructs 
require  more  attention.  Spreadsheet  developers  seem  to  be  cleaning  up  thier  products; 
newer  versions  are  reported  to  formalize  macro  languages  and  fix  irregularities. 

Finally,  the  database  utility  of  qneadsheets  could  be  enhanced  by  adding  a  jom  operation. 
Selectkxi  and  projection  operations  are  currently  supported.  Theadditionof  join  would 
make  spreadsheets  adequate  as  relational  database  management  systems. 
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A  DesaiDtion  of  the  Daily  Aircrew  Sctieduling  Problem  and  the  Scheduler  Prototype 

Single-seat  aircraft  aircrew  scheduling  is  typical  of  well-defined,  constraint-based 
scheduling  problems.  Briefly,  an  aircrew  scheduling  officer  in  an  operational  squaditxi 
must  complete  a  schedule  Ute  the  one  shown  in  Figure  1  by  filling  in  qrproptiate  pilots. 
Oxistraints  include  pilot  qualification,  pilot  availability,  training  event  requirements,  and 
event  currencies.  Pilot  qualification  ranges  from  Missirm  Qualffication  Training  t^ugh 
Mission  Ready,  2-Ship  Flight  Leader,  4-Ship  Flight  Leader,  and  finally.  Instructor  Pilot 
These  values  are  map^  into  the  nurribers  1-S  in  the  database  fOT  convenience  in 
manipulation  (See  Hgure  2).  Pilot  availability  is  subject  to  having  been  previously 
scheduled  to  fly  or  a  number  ci  Duties  Not  hicluding  Flying  (Dh^.  Typ^  DI^  ate 
things  like  medical  reasons,  leave,  TDY,  ground  training,  or  staff  duties.  Each  training 
term,  pilots  must  conqrlete  a  certain  nunti^  of  training  requirements  for  each  mission  or 
event  type  (See  Figure  3).  We^ns  delivery  (WD),  air  combat  trairung  (ACBT),  and  otiier 
types  of  training  sorties  give  pilots  training  c^portuiuties  for  different  events.  For  most 
events,  pilots  are  requited  to  maintain  a  currency;  for  exanq)le,  a  werqnns  delivery  mission 
must  be  flown  every  30  days  to  maintain  currency  (See  Figure  4).  Pilots  who  go  out  of 
currency  in  an  event  must  have  an  instructor  pilot  fly  the  same  mission  along  with  tiiem  the 
next  time  they  fly  that  event  Instructor  pilots  are  required  for  any  pilot  in  Mission 
Qualificatitm  Training  and  for  any  qualification  upgrade,  as  well. 

Training  event  requirements  and  currencies  act  as  drivers  in  the  scheduling  process,  while 
currencies,  qualificatimis,  and  availability  constrain  scheduling.  Currencies  are  paiticulariy 
important  because  instractor  pUots  are  a  valuable  resource  to  tile  schechiler.  Thoefore,  it  is  ' 
inqxirtant  to  schedule  pilots  who  will  soon  gp  oat  of  currency  befne  an  instructor  pilot  will 
have  to  be  scheduled  to  fly  with  them.  It  is  not  immediatBly  necessary  to  schedule  non- 
cunent  pilots  sitK:e  they  have  to  fly  witii  an  instructor  ^ot  anyway,  but  ^y  have  to  be 
schedule  sometirrie  or  they  will  be  unabk  to  complete  trairung  requirements.  Motiier 
things  being  equal,  plots  r^uiring  the  most  training  events  should  be  scheduled  first 

BefcHC  scheduling  pilots,  it  is  necessary  to  decide  which  the  mission  type  should  be 
scheduled  first  as  filling  these  slots  wtil  intact  i^ot  availability.  Oar  current  prototype 
doesn’t  consider  future  availability  of  training  missions.  Instead,  it  schedules  tiie  scarcest 
missioa  type  first  Algorithmically,  it  fiUs  the  schedule  from  the  bottom  up,  the  idra  b^g 
that  the  scheduling  officer  should  place  tiie  missions  on  the  schedule  in  onto  increasing 

scarciqr.  Althou^  tiiis  method  is  sinqtlistic,  it  is  used  by  noany  squadrons,  particularly  in 
the  early  months  of  tiie  trairung  term.  Fumre  smtie  types  are  not  completely  constrained 
and  are  (^n  not  knowiL  However,  more  rigorous  algorithms  are  possibte.  For  exanqile, 
our  KEE  scheduler  uses  scarcity  initially,  but  then  switches  to  an  algraithm  based  on 
assigning  individual  and  unit  mission  priorities  which  are  based  on  training  events  and  time 
remaining. 

While  the  above  description  of  the  scheduling  process  is  admittedly  sinqilistic,  it  is 
sufficient  for  describing  the  scheduling  process  and  the  visual  programming  methodology 
used  to  construct  the  aircrew  sdieduling  pototype.  Additional  elements  of  the  aircrew 
scheduling  problem  are  contained  in  [1]. 

The  data  used  by  the  prototype  consists  of  the  contents  of  Figures  2-4  and  is  consolidated 
in  the  prototype  into  one  database  (See  Hgure  5).  Below  the  ccxisolidated  database,  there 
is  a  row  containing  the  same  attribute  headings  as  the  database.  This  row  and  die  row 
below  it  make  up  a  criteria  array  which  essentially  is  the  query  specification  for  selection  in 
the  database.  By  editing  the  criteria,  different  rows  from  the  darabase  will  be  returned 
when  a  selection  is  r^uested.  For  example,  the  Availability  criteria  is  [nothing],” 

meaning  that  a  selection  will  return  any  row  with  a  blank  value  for  Avaih^ty.  Just  under 
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Figure  5.  Consolidated  Database,  Criteria,  and  Daily  Schedule 
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the  criteria  array  is  the  daily  schedule  being  filled  in  as  the  algorithm  executes;  its  rows 
contain  data  or  data  abstractions  to  be  past^  into  the  criteria  section  each  time  a  new 
selection  needs  to  be  made. 


During  execution,  the  scheduler  prototype  selects  the  last  unriUed  mission,  pastes  the  pilot 
qualification  requirement  in  the  criteria,  and  pastes  a  currency  range  in  tiie  criteria  ftv  tiie 
mission  being  filled.  At  that  pdnt  fonnulas  on  the  spreadsheet  which  calculate  greatest 
training  requirements  are  recalculated,  these  values  are  zero  (blank),  that  ind^ates  tiiat 
no  pilot  meets  the  current  criteria,  and  the  program  relaxes  the  currency  ctmstraint  by 
pasting  in  an  alternate  range.  Alternatively,  the  program  pastes  the  result  of  the  gret^t 
training  requirement  into  the  criteria,  and  selects  the  pilot  specified.  Next  the  program  tests 
to  see  u  an  instructor  pilot  is  ^uired  and,  if  so,  searches  for  one  who  is  available  and 
current  If  an  instractOT  pilot  is  needed  and  none  can  fly,  the  program  will  not  fly  the 
unqualified  or  non-current  pilot  Otherwise,  the  program  ma^  the  pilot’s  Availability 
attribute  “flying”  and  places  the  pilot  on  the  schedule.  If  an  instructor  pilot  is  required,  the 
program  up^tes  the  qualification  requirement  for  the  next  pilot  to  be  scheduled.  The 
algorithm  continues  until  all  sexties  are  scheduled  or  until  pilot  resources  are  exhausted. 

The  algorithm  is  not  rigorous  and  doesn’t  q)timize  on  things  like  instructor  pilot  utilizaticHi. 
In  addition,  it  currently  doesn’t  do  any  backtracking  to  remove  previously  scheduled  pilots 
to  fill  other  slots  where  they  might  be  needed  mtne.  Any  manual  entries  made  to  the 
schedule  should  be  constraint-checked,  a  feanire  not  currently  implemented.  However,  tire 
algoritiun  is  less  than  120  lines  oi  code;  these  additicnal  enhancements  are  planned  and 
ewtid  be  in^lemented  by  almost  anyone. 

Additional  Features  of  the  Scheduler  Prototype 


Our  KEE-based  aircrew  scheduler  has  a  number  of  utility  features  which  are  desirable. 
Some  of  these  features  have  been  implemented  in  the  new  prototype,  while  others  are  yet  to 
be  implemented.  The  prototype  allows  the  addition  and  deletion  of  pilots,  color  graphs  of 
pilot  data,  pilot  debrie^g,  auttxnatic  {xopagation  of  pertinent  data  throughout  the  database, 
and  d^lay  of  database  projections.  The  proto^pe  runs  under  Microsoft  Excel,  version 
IJ  on  an  Apple  Madiuosh  or  on  any  IBM-comp^le  personal  computer.  The  Macintosh 
version  inclum  pull-down  menus  ^  plays  a  portion  of  Beethoven’s  Fifth  Sym{tiiony  on 
completing  the  schedule. 

Our  current  scheduler  lacks  the  ability  to  incorporate  priorities  from  squadnxi  commanders 
or  other  supervisors.  Events  must  be  added,  changed,  and  deleted  manually.  Certain  data 
structures  on  the  prototype  are  sensitive  to  changes  and  should  be  protected  by  locking  the 
spreadsheet  cells.  Once  the  scheduler  design  is  relatively  stable,  a  user’s  manual  is 
required.  All  of  these  enhancements  are  planned,  as  is  a  more  rigorous  scheduling 
alj^tiun. 


Omcludingri 


•/till 


The  use  of  spreadsheets  as  a  visual  programming  language  is  particularly  useful  for  a 
number  of  different  problenu  which  have  some  or  all  of  the  following  attributes:  (1)  data- 
intensive,  (2)  hard  to  define,  (3)  require  fourth-generation  functions,  or  (4)  benefit  from 
data  abstraction.  In  addition,  ^nea^eets  are  Mendly  for  novice  programmers  and  helpful 
fex  r^d  prototyping  as  well. 
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APPENDIX  C 


The  following  paper  describes  the  object-oriented  paradignL  It  resulted  trom 
graduate  seminar  research  into  mediodologies  for  neural  network  simulaticxi,  bu?:  many 
comments  made  apply  to  object-oriented  programming  in  general 
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On  Object-Oriented 
Programming  and  Simulation 

Douglas  E.  Dyer 

Introduction 

It  is  well  known  that  small 
computer  programs  are  easier  to 
develop,  debug,  and  modify  than  large 
piogra^are.  Mc»e  accurately,  it  is  the 
coaq)lexity  of  the  program  that  dictates 
how  well  humans  can  work  with  a  it 
Some  very  large  programs  are  quite 
well  undentot^  because  they  are 
relatively  simple.  For  example, 
government  accounting  and  payroll 
applications  are  thousands  of  Imes  long, 
but  are  made  up  of  many  similar 
modules;  accounting  principles  are  well 
understood.  In  contrast  a  much 
smaller  expert  system  can  elude 
understan^g  for  years  because  the 
process  it  models  is  so  dif&nilt  to 
characterize. 

The  complexity  of  programs 
arises  finom  two  basic  reasons:  the  real- 
world  system  to  be  modeled  and  its 
coded  representation.  If  the  system  is 
not  well  understood,  as  in  the  study  of 
cognition,  then  a  computer  program 
which  attenq)ts  to  nao^  it  caiuiot  be 
successful.  Successful  computer 
programs  are  those  whidi  ej^loit  the 
power  of  the  coo^uter  to  sdve 
problems  whidi  (1)  people  find  difficult 
to  sdve  and  (2)  can  be  programmed. 
The  computer  is  powerful  because  it  has 
non-volatile,  expandable  memory  and 
can  process  information  quickly  and 
painlessly,  once  programmed. 
Unfortuiiatdy,  computen  lack  common 
sense  and  most  do  not  tolerate  noisy 
input  The  above  discussion  is  not 
meant  to  inqily  that  artificial  intelligence 
research  is  a  wastt  of  time. 
Programming  can  be  used  as  a  tool  for 
thought  for  example,  an  aid  in 
cognitive  modd  d^lopment  and 
testing. 

If  the  system  to  be  modeled  is 
not  well  understood,  the  main  problem 


is  elucidating  the  system,  and  that 
problem  lies  somewhat  outside  of  the 
realm  of  computer  sdence. 

However,  complexity  can  also 
arise  fiom  the  prognun  and  coding 
process.  That  is,  given  a  well 
understood  system,  a  program  which 
modds  the  s^tem  may  s^  be 
unmanageably  difiicult  to  develop, 
debug,  ^  maintain.  Areal-wcdd 
system  does  not  have  to  be  very  large 
b^ote  the  complexity  of  its  co^ 
representation  becomes  overwhelming. 
Computer  scientists  have  been 
struggling  with  this  problem  for  over 
thirty  years.  Many  solutions  ^ 
methodologies  have  been  proposed  and 
accepted.  The  formal  discipline  of 
software  engineering  is  dedicated  to 
improving  ^e  process  of  building  large 
programs.  In  my  opinion, 
representational  complexity  is  die 
fundamental  problem  of  computer 
sdence. 

Some  oi  the  developed  tools  and 
methods  for  dealing  with  complexity  in 
computer  programs  have  been  very 
good.  Opmting  systems  relieved  the 
programmer  of  much  work  by 
abstracting  house-kwping  details. 
Higher-ocdered  langrages  reduced  the 
amount  of  code  requir^  to  do  a  task 
and  also  work  by  abstracting  lower 
level  operations.  Structured 
programming  encon^asses  modularity 
and  structure;  noodul^ty  allows  us  to 
mentally  deak  programs  into  separate 
pieces  and  structure  allows  us  to 
mentally  stack  the  pieces  in  a 
recognizable  way. 

Other  techniques  for  improving 
programs  and  the  programming  process 
indude  prottfs,  compiler  syntax 
checking,  smart  editors,  using  different 
{TOgramming  languages,  and  using  a 
sin^,  standi  programnting 
language.  (Scane  languages  ate  better  at 
certain  problems  than  othm  ate. 
Another  school  of  thought  attempts  to 
use  only  one  programnting  language  to 
reduce  fluency  requirements  and  give 
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programmers  a  common  language. 
Features  of  programming  languages  are 
now  studied  extensively  to  find 
strengths  and  weaknesses.)  However, 
none  of  these  tools  or  approaches  have 
been  shown  to  impact  coisplexity  like 
abstraction,  nxxlidarity,  and  structure, 
which  are  clearly  more  fundamental 
ideas. 

Object-oriented  programming,  a 
relatively  new  programming 
methodology,  is  based  on  a  data- 
centered  viewpoint  Object-oriented 
programming  grew  from  fundamental 
roots:  abstraction,  modularity,  and 
structure.  Its  four  identifying  elements 
are  object  encapsulatitxi,  message 
passing,  dynamic  binding,  and 
inheritance.  Those  four  elements  can  be 
thought  of  as  unique  extensions  of 
abstraction,  modularity,  and  structure. 

In  object-miented  programming, 
objects  in  die  code  represent  elements 
(nouns)  in  a  real-world  system.  This 
^iptoach  differs  from  most  algorithmic 
languages  Uke  Pascal  or  C  which  tend 
to  focus  on  procedures.  For  this 
reason,  objea-oriented  programming  is 
a  good  methodology  for  handling 
representational  complexity  (rf  data- 
centered  models.  Simularion  is  a  one 
exarrqile  of  a  problem  in  which  real- 
world  events  are  often  data-oentered, 
rather  than  algoridunically-oentered. 

This  paper  discusses  the  three 
traditional  ways  of  handling 
representationial  complexity, 
abstraction,  modularity,  arid  structure, 
as  well  as  their  extensions  as  elements 
of  object-crirated  progiam^g.  Three 
(rf  the  ehanents  of  obg^-orient^ 
programming,  object  encapst^on, 
message  passing,  and  dynamic  binding, 
will  be  futher  dncribed  in  a  discussion 
of  a  Scheme  digital  circuit  simulator. 
AdditkHial  exan^les  (rf  the  use  of 
object-oriented  programming  in 
simulation  will  be  Mefly  described. 


Abstraction,  Modularity,  and 
Structure. 

Abstraction.  Because  humans  have 
volatile  merriory,  the  number  of  items 
we  can  mentally  manipulate  is  limited. 
Only  througli  absttacticm  are  we  able  to 
cogitate  on  any  but  tire  sinq)lest 
concepts.  It  h^  been  theonzed  tiiat 
only  seven  mental  objects  can  be  stored 
and  recalled;  the  abstraction  process  to 
remember  more  than  seven  (Ejects  is 
called  "chunking"  to  indicate  the  need  to 
aggregate  sever^  objects  as  one.  The 
id^  of  chunking  was  fundamental  in 
breaking  up  identification  numbers  such 
as  social  security  numbers  and 
telephone  numb^,  but  it  also  give 
insight  into  the  need  for  abstractitxi  in 
the  programming  process. 

By  definition,  abstraction  is 
associating  a  group  of  objects  wifr  a 
single  "group-of-objects"  idea.  Often 
we  use  a  label  to  represent  the  conc^t 
As  an  example,  the  process  of  addition 
is  signified  by  "+"  when  it  actually  is  a 
pnx^ure  for  m^ing  two  numbers 
into  a  third. 

The  power  that  abstraction 
offers  is  that  it  rdieves  us  of  having  to 
think  about  details  which  we  don't  need 
tt>  diink  about  aixl  allows  us  to  focus  cm 
the  real  problem.  Imagine  how  difficult 
it  would  be  to  calculate  die  sum  of  two 
numbers  if  not  for  abstraction!  If  you 
have  a  calculator  and  want  to  calcidate 
"2  +  3"  you  have  to  know  how  to  push 
the  buttons  but  not  how  the  calculate 
works.  You  don't  need  to  know  that  the 
calculator  has  to  have  registers,  an 
aridimetic/logic  unit,  control  software, 
data  paths,  and  an  input/ouqnit 
interface.  At  lower  level,  yw  don’t 
need  to  know  how  to  inqrlement  a  gate 
or  flip-flop;  at  a  still  level,  you 
don't  need  to  know  the  solid-state 
physics  behind  semiconductor 
behavior.  Gearly,  you  don't  care  how 
the  calculator  works;  thaf  s  not 
irxqiortant  You  view  it  as  an  abstract 
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black-box  duu  does  die  addition  that 
you  need 

Using  a  label  as  a  mnemonic 
representation  of  an  abstract  idea  seems 
to  be  important  for  memory 
maintenance  and  mental  manipulation. 
Once  you  have  a  name  for  something, 
you  can  mss  it  around  in  you  head,  2^ 
or  delete  facets  from  it,  and  relate  it  to 
other  mental  objects  without  fear  of 
l<»ing  or  misaligning  it  It's  yours  to 
keep.  We  use  h^Umg  or  naming  all 
the  time,  but  it  is  e^iedally  apparent  in 
techiucal  fields  in  the  form  of  jargon. 
For  example,  names  like  "method,” 
"message,"  and  "package"  have  special, 
complicated  meanings  to  those  who 
study  object-oriented  programming. 

Abstraction  can  be  used  to 
develop  a  higher-ordered  language.  A 
set  of  related  abstract  objects  can  be 
thought  of  as  a  language  which  can  be 
used  to  solve  problems.  As  an 
exanqile,  if  you  consider  the  set  ( -t-  -  * 
/  {real  numbers) ),  you  get  the 
language  (tf  elemental  arithmetic,  bi 
computer  science,  all  higher-onlered 
languages  like  Pascal  are  based  on  a  set 
of  abstracted  machine  langiuige 
operations  and  routines  which  have 
bMn  named  things  like  "read,"  "write,” 
"if,"  and  "while-do"  as  weU  as  "+," 
etc.  Objea-orknted  programming,  as  a 
methodology,  he^rs  generate  absti^ 
languages.  The  language  of  digital 
circuit  simulation  is  one  example. 

Whenever  the  level  of 
abstraction  is  not  great  enough  to 
facilitate  problem  solving,  finther 
abstraction  may  be  used  to  make  a  still 
higher  level  language.  For  example,  it 
may  not  help  to  thi&  in  terms  of  the 
fiitictions  available  in  Pascal,  like  "read" 
and  "write".  Instead,  you  may  prefer 
"input-procedure"  and  "output- 
procedure."  Abstracting  clusters  of 
code  in  a  given  computer  language  can 
yield  a  new,  higher-level  language  of 
software  modules.  The  language  of 
software  modules  is  currentiy  a  goal  of 
software  engineering  and  is  siq>parted 


by  object-oriented  programming.  (Cox 
calls  these  modules  "software  integrated 
circuits.") 

There  are  drawbacks  to  using  an 
abstracted  language  such  as  the 
language  of  con^uter  mobiles. 
Naturally,  you  have  to  learn  the 
language;  that  can  invdve  reading  a  lot 
of  documentation.  Sometimes  die 
language  is  not  appropriate  to  your 
problem.  Sometimes  the  langur^e  was 
not  well  thought  out  and,  altlwu^ 
intended  to  solve  your  problem,  it 
doesn't  do  a  very  nice  job.  Sometimes 
the  language  is  reasonably  goody  but  the 
documentation  is  lacking,  tfthe 
programmer  doesn't  trust  the  language, 
much  time  may  be  wasted  by  wa^g 
down  into  the  depths  of  lower 
abstraction  layers  to  make  sure  they 
wok.  Although  all  these  problems  are 
real,  they  don't  detract  from  die  power 
of  abstraction;  rather,  they  ate 
implementation  issues. 

Gerald  Sussman  has  said  that 
the  best  sdution  to  complex  problems 
often  looks  more  like  layers  of 
languages  rather  than  pieces  of  code 
which  solves  pieces  (tf  the  probleriL  In 
his  Computer  Exercises  work  book, 
there  are  many  mrae  examples  of 
languages  built  from  abstracted  objects, 
including  languages  for,  drawing 
Escher  (tiagrams,  drawing  squares  and 
triang^  and  simulating  spa^  mission 
operations.  These  exarx^l^  clearly 
illustrate  that  abstraction  is  a  powofiil 
method  for  controlling  complexity  in 
computer  programming. 

Modularity.  Modularity  is  the  practice 
of  building  walls  around  pieces  of  code 
and  forcing  different  pieces  to 
communicate  only  by  well-defined 
communication  duumels.  The  idea  ttf 
"wall"  and  "contract"  in  Helnon  and 
Veroff  is  the  essence  modularity. 

Modularity  goes  hand  in  hand 
with  the  notion  of  abstraction. 
Modularity  is  the  package  ^riiich  binds 


93 


an  abstraction  and  allows  you  to 
manipulate  it  as  a  whole  entity. 
Modularity  also  allows  different  pieces 
of  code  to  be  structured  -  you  must  be 
able  to  cleauiy  define  a  piece  before  you 
can  arrange  a  group  of  pieces. 

Code  is  modular  when  the 
package  binding  it  keeps  it  from 
affecting  anydiing  out^de  it  except 
through  weU-defuied  interfaces. 
Theoretically,  modular  code  may  be 
sltqiiped  in  or  out  of  a  software 
environment  by  altering  only  the 
interface  between  TiKxlules.  Code 
behavior  can  be  isolated  to  each  module; 
bugs  are  easily  contained,  found,  and 
corrected. 

In  practice,  nxxlularity  does  aid 
in  debugging  and  makes  a  program 
more  tractable.  However,  the  interface 
on  eadt  package  must  be  explicitly 
specified  constructed,  and 
documented.  In  addition,  a  good 
inq)leinentatu»  lequiies  that  the  code 
innde  each  package  be  "buUet-pcoor  so 
that  ifs  never  necessary  to  give  up 
abstraction  to  fix  an  in^lementation 
detail. 

Structure.  The  advent  of  structured 
programming  in  the  early  1970s  gave 
programmers  a  new,  powerful  for 
deaOng  with  representational  complexity 
in  programs.  Structured  programming 
mr^  "goto"  a  four-lettered  word  for 
programmers;  it  showed  that  the 
dangerous,  undisciplined  "goto"  code 
could  be  replaced  in  all  cases  by 
sequential  coding. 

The  major  contributioa  of 
structured  prograrnrmng  is  that 
modularity  is  enforced.  However,  an 
important  secondary  contributioa  is  diat 
the  rriodular  pieces  are  placed  with  some 
relation  u>  one  another,  and  hence,  have 
a  structure.  The  structure  of  the 
modules  can  be  rearranged  to  change 
the  program  -  in  effect,  these 
rearrangements  and  the  changes  which 
result  t^e  up  the  language  ^  structure 


inaprograra  More  itrq)ortantly,  the 
strucnire  of  the  program  is  inqwrtant  in 
helping  the  pre^ammer  to  mentally 
manipulate  the  prograta  This  is  true, 
or  programmer’s  would  not  care 
whether  a  program  were  properly 
indented  or  merely  a  long  string  of 
statements  widi  no  white  space  at  alL 

Structure  also  encompasses  the 
decision  about  how  large  to  make  the 
program  modules.  In  practice,  a  certain 
balance  between  components  at 
different  levels  oi  abstraction  is 
important  It  doeai't  help  to  have  ten 
hi^-  level  components  and  just  1  low- 
level  one  (or  vice  versa).  Instead,  it 
often  makes  more  sense  to  use  two  cr 
three  higher-level  components  for  every 
five  to  seven  lower-level  ones.  This 
heuristic  extends  for  multiple  levels. 

Abstraction,  modularity,  and 
structure  are  all  somewhat  relai^  In 
additkm,  they  all  serve  to  he4>  die 
programmer  combat  c(»iq)lexiQr  when 
trying  to  tefnesent  a  naodel  as  a 
computer  trogram.  Modularity  turns  a 
program  into  individual  code  pieces. 
Abstraction  gives  each  piece  a  meaning 
and  a  name.  Structure  shows  how  the 
pieces  are  related  to  one  another.  If  all 
three  are  deme  correctly,  the  {xogram 
can  fit  into  the  brain  a^  make  sense. 

Elements  of  Object-oriented 
Programming:  Object 
Encapsulation,  Message  Passing, 
Dynamic  Binding,  and 
Inheritance. 

Object-oriented  programming 
takes  advantage  of  abstnrction, 
modularity,  a^  structure,  but  extends 
them  in  unique  ways.  In  object- 
oriented  programming,  the  focus  is  on 
the  "object"  What  is  an  object?  hr 
most  programming  languages, 
progrtmos  conrist  of  procedures  to  and 
hom  which  data  are  passed.  The 
procedures  "do"  something  and  are  like 
verbs  in  the  spoken  language.  In 
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object-oriented  programming,  programs 
consist  mainly  of  "Ejects"  which 
consist  of  "non-passive"  data.  That  is, 
if  procedures  are  the  verbs  of  spoken 
language,  objects  are  really  mrae  like 
the  nouns. 

What  does  it  mean  to  be  "non¬ 
passive?"  Conventional  programming 
languages  (baw  a  clear  distinction 
between  procedures  and  data. 
Languag^  like  Scheme  question  that 
philosophy  and  treat  both  as  first-class 
objects,  many  Scheme  progia^, 
ifs  very  difficult  to  say  that  a  particular 
entity  is  one  OT  the  other.  Even  in 
speech,  nouns  rest  on  a  scale  between 
extremes  of  passiveness  arid  action. 
Most  humans  would  interpret  the 
sequence  of  nouns  "rock,"  "hammer," 
"recipe,"  and  "programmer"  to  have  an 
increasing  implication  of  action. 

Object  Encapsulation  and 
Message  Passing.  Objects  are 
composed  of  data  and  tiie  procedures 
which  qperate  on  it,  as  well  as  an 
interface  to  other  objects.  Objects 
maintain  an  internal  definition  of  state. 

In  this  way,  an  object  can  be  said  to 
"know"  something  about  itself  —  it 
knows  its  own  state  and  the  operations 
which  can  change  its  state. 

Owventional  programming 
langua^  often  abstr^  procedures 
primarily  and  data  structures 
secondarily.  That  is,  the  abstraa  data 
type  has  relevance  <^y  in  context  of  the 
ptwedures  which  operate  on  it  In 
object-oriented  programming,  this 
viewpoint  is  revors^  It  is  data  which 
is  abstracted  in  a  primary  sense. 
Procedures  which  operate  on  an  object 
are  only  a  part  of  die  object  itself.  This 
type  abstraction  is  unique  to  object- 
onented  programming. 

The  object  data,  procedures,  and 
interface  are  all  enclosed  in  a  hard  shell 
of  encapsulation.  By  design,  it  is  only 
through  the  interface  that  die  object  can 
communicate  with  other  objects.  In  this 


manner,  strict  modularity  is  enforced. 
Instead  of  using  a  direct  procedure  call 
with  data  passing,  the  object-oriented 
paradigm  uses  message  passing 
between  objects  to  execute  a  program. 

A  message  is  a  request  from  one  object 
to  another  to  cause  some  action  to  take 
place.  Control  is  retained  by  the  object 
~  a  request  may  be  denied,  and  it  c^n 
is  if  die  object  is  not  wmldng  properly. 
The  "procedure-  with-arguments"  call 
in  a  conventional  programming 
methodolo^  seems  to  be  a  w^er  kind 
ofmodulari^.  Message  passing  is  a 
unique  way  implementing  modularity 
and  is  an  extension  on  "procedure  ctdl" 
modularity.  In  addition,  by  using 
messages,  it  is  easier  to  create  a 
standard  interface  for  objects. 

Dynamic  Binding.  Binding  refers 
to  putting  data  together  with  tte 
procedure  which  affects  it 
ConventxMud  languages  like  C  and 
Pascal  require  the  programmer  to 
manage  banding  up  frrat.  It’s  up  to  the 
programnoer  to  determine  the  correct 
(lata  type  and  pass  that  type  to  a  type- 
depen^nt  procedure,  ^me  languages 
(Ada,  for  example)  delay  binding  until 
compilation,  lliis  appn^h  allows  the 
programmer  to  use  just  cme  procedure 
name  for  different  types  of  data.  The 
conqrikr  determines  die  data  type  and 
selem  the  correct  procedure  to  iqiply. 
Only  low-level  procedures  are  ^le- 
dqioidroL  The  advantage  (rf  delayed 
binding  is  that  the  programmer  is 
allowed  to  (diange  data  types  without 
changing  high-level  procures.  Other 
languages  (Smalltalk)  delay  binding  still 
further  until  run  time.  This  adds  s^ 
greater  flexibility  as  data  types  may  be 
changed  on  the  fly.  The  program  itself 
may  even  change  the  tj^  and  still 
(^leraie  properly.  Agi^  low-level 
procedures  will  be  type-dqiendent 

In  terms  of  die  object-oriented 
design,  late  (dynamic)  binding  offers 
some  rod  advantages.  With  dynamic 
binding,  all  but  the  lowest  class  of 
object  is  type-independent  This  is 
another  radier  unique  implementation  of 
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modulari^.  When  injects  are  cype- 
independrat,  they  are  more  easily 
manipulated  and  reused.  Dynamic 
binding  does  incur  some  overhead  in 
terms  ^  space  and  execution  time;  it  is 
responsible  for  the  object-oriented 
pai^gm's  reputation  for  sluggish 
performance.  However,  the  added 
flexibility  derived  from  delayed  binding 
is  very  useful  during  prototyping. 

Inheritance.  Inheritance  refers  to  a 
certain  way  of  structuring  information. 

It  is  recogni^  as  a  prirnaty  means  of 
classifying  information  in  humans. 
InlMEritance  is  information  stored  in  a 
hierarchial  structure,  as  a  tree  with 
parents  and  children,  and  the  children 
gain  information  (inherit)  from  their 
parent  nodes.  The  "ISA"  and  "A- 
KIND-OF*  hierarchies  found  in 
artificial  intelligence  literature  are 
examples  iid^tance.  Obj^- 
oriented  programming  is  rel^vely 
unique  in  using  inheritance  as  a  way  ci 
structuring  a  program. 

Using  inheritance,  an  object  has 
access  to  data  and  procedures  of  all  of 
its  superclasses,  as  well  as  its  own. 

For  example,  an  obj^  "SHERMAN 
TANK"  might  contain  information 
about  the  the  thickness  of  its  armor,  its 
maximum  speed,  and  die  size  of  its 
gun.  However,  "SHERMAN  TANK" 
would  also  have  access  to  general 
infwmation  from  its  immolate 
mperclass  'TANKS"  which  might 
include  situations  in  which  tanks  ate 
effective  and  wetqxxis  which  are 
effective  against  tanks.  Progressing 
further  up  the  hierarchy,  "SHERMAN 
TANK"  would  also  have  access  to 
infotmatioa  fiom  higher  superclasses. 

If  "GROUND  VEHICXES"  were  a 
superclass,  "SHERMAN  TANK"  might 
gain  usehil  information  from  it,  for 
example,  ground  vehicles  can't  operate 
in  de^  water. 

Inheritance  makes  it  possible  for 
object-oriented  designs  to  avoid  storing 
a  lot  of  repetitive  information.  This 
makes  the  code  mote  coir^act  and 


sinqiler.  It  is  an  effective  structuring 
mechanism  for  reducing  program 
complexity.  In  addition,  inheritance 
adds  greatly  to  the  modularity  and 
modifiability  of  the  code.  Information 
that  is  stored  in  only  one  place  is  easier 
to  noodify  dian  when  it  is  scattered 
throughout  the  program.  Furthermore, 
inheritance  is  pwerfiil;  a  diange  to 
information  in  that  one  place  can  affect 
many  child  objects  at  once. 

The  elements  d  object-oriented 
progrrunming  build  upon  and  extend 
traditional  niethods  of  dealing  with 
representational  conqilexity.  Object 
encrqisulation  treats  ^ta  as  the  primary 
object  to  be  abstraaed  and  made 
modular.  Message  passing  is  made 
necessary  by  object  encapsulation. 
Messages  are  abstract,  weak  procedures 
that  act  as  requests  for  action  by 
objects.  Messes  promote  iTK^ularity 
because  they  are  indq)endent  of  the 
proc^ures  they  request  Dynamic 
binding  enhanm  n^ularity  by 
allowing  hi^er-level  objects  to  remain 
typeiiul^ndent  Inheritance  increases 
modulari^  dranratically  and  is  a 
structural  arrangement  relatively  unique 
anrong  programming  methodologies. 

Object-Oriented  Programming 
in  Simulation. 

In  object-oriented  programming, 
there  is  often  aone-to-one 
correspondence  between  real-wmld 
objects  aixl  objects  in  aprogranmied 
model.  In  a  war  simulation,  for 
example,  'TANKS"  would  represent 
teal  tanks  and  would  be  expected  to 
model  real  tanks  approfniaiely. 
Therrfore,  the  object-oriented 
prograrrmaing  methodology  would  seem 
to  be  well  suited  for  sittrulation. 

The  Scheme  prograrrrtrring 
language  is  a  dialect  (tf  LISP.  The 
Texas  Instruments  in^lementation  of 
Scheme  includes  SCXX)PS,  an  object- 
oriented  programming  environment 
Scheme  is  a  small  language  developed 
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by  MIT  and  other  universities  to  show 
that  a  single  language  could  treat  a  wide 
variety  of  different  problems,  including 
traditional  and  symbolic  ones. 

Although  there  are  some  very 
important  differences  between  Scheme 
and  Commcm  LISP,  they  both 
dynamically  check  data  types. 

However,  Scheme  treats  bodi 
procedures  and  data  as  first-class 
objects.  That  is,  procedures  can  be 
passed  as  arguments  to  other 
procedures  ^  can  be  returned  by  still 
other  procedures.  This  treatment 
necessarily  blurs  the  distinction  between 
data  and  procedure. 

Abelson  and  Sussman  present  a 
Scheme  digital  circuit  simulator  which 
can  be  used  to  make  elements  of  object- 
oriented  programming  more  concrete. 
The  SCOOK  environment  was  not 
used  to  develq)  the  code,  however,  so 
the  inheritanoe  aspects  are  implied, 
rather  than  explicit  Refertothe 
A[^ndix  for  a  modified  version  oi  the 
simulator  code. 

In  Abelson  and  Sussman's 
circuit  simulator,  wires  are  the  primary 
object  Other  objects  such  as  inverters, 
and-  and  or-gates  and  pro^  send 
messages  to  wires  requesting  various 
actions.  Ifigher-level  objects  like  half- 
andfuU-  adders  are  made  from  lower 
level  ones.  An  agenda  and  the  various 
data  structures  needed  for  it  are  also 
implemented  in  die  code. 

Gxisider  the  wire  objea 
identified  in  the  Scheme  code  as  the 
MAKE-WIRE  (tefinition  (under ;; 
Objects  ■■■■mi  If).  In  the  co^,  a 
wire  knows  its  vdtage  value  initially 
and  at  any  time  during  the  simulation  as 
SIGNAL-VALUE.  The  data  type  of 
SIGNAL- VALUE  is  numeric,  t»t  that 
doesn't  matter  until  runtime,  because  of 
Scheme's  dynamic  binding.  If  we 
choose,  we  can  alter  SIGNAL- 
VALUEs  type  without  changing 
MAKE-Wn^  The  wire  object  also 
knows  the  procedures  that  can  affect  its 


data,  namely  SET-MY-SIGNAL  and 
ACCEPT-ACnON-PROCEDURE. 

The  latter  procedure  propagates  signal 
value  changes  to  other  wires  to  carry 
out  the  simulaticm.  Notice  that  only  the 
wire  objea  can  run  either  procedure.  A 
wire  must  receive  an  exter^  message 
before  dispatching  on  it  and  executing 
whatever  procedure  it  choc^es  as 
apprc^niate.  Thus,  the  wire  objea  is 
firmly  encapsulated  in  a  hard  shelL  The 
interface  b^een  die  objea  and  external 
objects  is  identified  as  the  message 
handler  DISPATCH.  Messages 
received  are  those  to  get  ot  set  a  wire's 
signal  (GET-SIGNAL,  SET-SIGNAL!) 
or  add  a  propagation  actioi  (ADD- 
ACnONI).  Any  other  message 
received  is  erroneous.  Because 
messages  only  request  action  (as 
oppos^  to  procedures  which,  when 
followed,  cause  it  to  happen),  the 
progr^  can  be  quite  modular. 
Inhmtance  is  not  demon^rated  by  this 
code,  as  it  was  not  itrqilemented  using 
SCOC^;  the  simulaior  hasn't  taken 
full  advantage  oi  die  objea-odented 
paradigm. 

The  digital  circuit  simulator 
serves  as  a  new  language.  Instead  of 
using  Scheme,  it  enisles  us  to  think  in 
terms  of  wires,  probes,  and- and  or- 
gates,  and  inverters.  With  this  new 
language,  we  can  build  even  higher- 
level  abstractions  like  half  and  full 
adders.  Although  the  code  is  really  quit 
sinqile,  its  objea-otiented  design  makes 
it  very  powerful  The  simulator  shown 
in  the  appendix  served  as  the  core  of  a 
very  a»^lex  computer  simulation. 

Those  na  familiar  with  Scheme 
or  other  LISPs  may  not  see  the 
s^lid^  and  powers  the  digital 
circuit  simulator.  However,  c^jea- 
oriented  methodology  has  been 
developed  for  odier,  more  convoitional 
languages  as  well.  As  an  example, 
Jacky  ^  Kalet  successfully  d^lq)ed 
a  lar^  Pascal  program  using  objea- 
oriented  concepts. 

There  are  odier  examples  in  die 
literature  of  the  use  objea-ociented 
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programming  in  simulation.  For 
example,  Eilbert  and  Salter  developed  a 
neural  network  simulator  in  Scheme. 
Their  Scheme  simulator  was  shown  to 
be  mcne  effective  at  modifying  netwcxk 
structure  and  the  node  updating  process 
than  simulamrs  based  on  standard 
numerical  languages.  In  addidon,  the 
Scheme  simulator  was  more  successful 
at  modeling  networks  which  are 
hierarchially  organi^  There  are  three 
major.Schetne  functions  in  the 
simulator  "(1)  a  netwcnk  generator 
which  specifies  the  structure  and  single 
node  response  of  the  model;  (2)  the 
netwOTk  evolver,  which  controls 
activity  iiutialization  and  the  updating 
process  for  the  network;  and  (3)  the 
Monte  Carlo  simulator,  which  ^ds  the 
stable  states  of  the  network  and  records 
them."  Nodes  in  the  system  are  the 
primary  objects.  Computations  on 
nodes  are  distributed  to  the  nodes 
themselves.  This  is  fundamentally 
different  fiom  a  FORTRAN  simulator 
that  the  authors  studied;  the  FORTRAN 
representatxHi  used  a  matrix  of 
connection  wei^ts  between  nodes  to 
calculate  convergence.  Tlie  authors 
point  out  that  the  FORTRAN  program 
is  intrinsically  faster  on  von  Neumatui 
noachines,  but  is  also  more  difficult  to 
transfer  to  a  parallel  architecture.  Asa 
neural  net  is  a  distributed  processing  - 
architecture,  it  seems  more  natural  to 
model  it  using  an  objea-  oriented 
design.  The  flexibility  of  using  the 
naore  accurate  Scheme  representation  is 
an  added  bonus.  To  generate  a 
representation  for  a  particular  model, 
the  object-oriented  ^heme  design  only 
has  to  call  the  network  generator  which 
makes  new  instances  of  nodes  as 
appropriate.  Also,  the  updating 
procedures  of  a  node  and  its  reqw^ 
curve  are  attributes  contained  widiin  die 
object  Local  or  global  changes  can  be 
m^  very  quickly  without  affecting  the 
rest  of  the  program,  because  of 
modularity,  l^ben  and  Salter  woe 
very  attracted  to  an  objea-oriented 
simulator  because  th^  wanted  to  model 
neural  nets  that  are  hierarchially 
structured.  The  message-passing  style 


of  Scheme  allowed  them  to  model 
interactions  between  hierarchial  levels 
quickly  and  accurately. 

Laiidn,  Cairuthers  and  Soper 
inqilemented  a  simulator  of  a  ship's 
navigation  system  in  Flavors,  an  objea- 
oriented  programming  language  ofiira 
found  on  LISP  machmes.  They  found 
that  object-oriented  programming  was 
ideally  suited  to  their  simulation  for 
three  reasons.  Hrst,  the  one-u>-one 
conespondence  between  code  objects 
and  r^-world  objects  helped  malcB 
development  clearer.  Second,  the 
advanced  fonn  of  modularity  inherent  in 
objea-oriented  programming  helped 
reduce  the  conplexity  and  ease 
maintenance  of  the  simulation  tools 
developed.  Finally,  the  structure  and 
nxxiularity  of  the  resulting  code  made  it 
very  extensible. 

m 

Staiimand  and  Kreutzer  built  a 
process-oriented  simulatiai 
environment  (POSE)  in  a  locally 
developed  objea-oriented  programming 
environment  (flavors)  running  under 
Scheme.  The  hierarchial  structure 
afforded  by  inheritance  is  key  to 
reducing  coiiq)lexity  of  the  FOSE 
representation  of  process  noodels. 

Conclusions 

Objea-oriented  programming  is 
an  effective  methodolo^  for  reducing 
the  complexity  of  programmed 
representation  of  models.  The  focus  on 
objects,  rather  than  procedures,  is 
fundamentally  different  from 
programming  in  a  standard  way  using 
omventional  languages.  The  four 
elements  (rf  objea-  oriented 
programming,  objea  encapsulation, 
message  passing,  dynamic  binding,  and 
inheritance  all  extend  traditional  ways  oi 
dealing  with  program  complexity: 
abstraction,  modularity,  and  structure. 
Objea-oriented  progrsuxumng  is  well 
suited  to  simulation  because  of  these 
unique  attributes. 
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APPENDIX 


;;  SIMULATION  -  DIGITAL  CIRCUrr======= 

;  Queue  Operations 

(define  (make-queue)  (cons  '0 '())) 

(define  (empty-queue?  queue)  (null?  (finont-ptr  queue))) 

(define  (front  queue) 

(if  (empty-queue?  queue) 

(error  "FRONT  called  with  an  empty  queue"  queue) 
(car  (front-ptr  queue)))) 

(define  (insert-queue!  queue  item) 

(let  ((ncw-pair  (cons  item  nil))) 

(cond  ((empty -queue?  queue) 

(set-fn»it-ptr!  queue  new-pair) 

(set-rear-ptr!  queue  new-pair) 
queue) 

(else 

(set-odr!  (rear-ptr  queue)  new-pair) 

(set-rear-ptr!  queue  new-pair) 
queue)))) 

(define  (delete-queue!  queue) 

(cond  ((craptyAiueue?  queue) 

(error  "Delete  called  with  an  empty  queue"  queue)) 
(else 

(set-front-ptr!  queue  (cdr  (front-ptr  queue))) 
queue))) 

(define  (front-ptr  queue)  (car  queue)) 

(define  (rear-ptr  queue)  (cdr  queue)) 

(define  (set-front-ptr!  queue  item)  (set-car!  queue  item)) 
(define  (set-rear-ptr!  queue  item)  (set-cdr!  queue  item)) 

;;  The  Agenda  =========—==—==»= 


(define  (make-dme-segment  time  queue)  (cons  time  queue)) 

(define  (segment-time  s)  (car  s)) 

(define  (segment-queue  s)  (cdr  s)) 

(define  (segments  agenda)  (cdr  agenda)) 

(define  (fiiit-segment  agenda)  (car  (segments  agenda))) 

(define  (rest-segments  agenda)  (cdr  (segments  agenda))) 

(define  (set-segixKnts!  agenda  segments)  (set-cdr!  agenda  segments)) 
(define  (current-time  agenda)  (segment-time  (first-segment  agenda))) 
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(define  (eiq)ty-agenda?  agenda) 

(and  (empry-qucue?  (segment-queue  (first-segment  agenda))) 
(null?  (rest-segments  agenda)))) 

(define  (add-to-agenda!  time  action  agenda) 

(define  (add-to-segments!  segments) 

(if  (s  (segment-time  (car  segments))  tune) 

(insert-queue!  (segment-queue  (car  segments))  action) 

Get  ((rest  (cdr  segments))) 

(cond  ((null?  rest) 

(insert-new-tinie!  time  action  segments)) 

((>  (segment-dme  (car  rest))  tin») 

(insert-new-dme!  time  action  segments)) 

(else  (add-to-segments!  rest)))))) 

(add-to-segments!  (segments  agenda))) 

(define  (insert-new-dme!  time  action  segments) 

(let  ((q  (make-queue))) 

(insen-queue!  q  action) 

(set-cdr!  segments 

(cons  (make-time-segment  time  q) 

(cdr  segments))))) 

(define  (temove-first-agenda-item!  agenda) 

(delete-queue!  (segment-queue  (first-segment  agenda)))) 

(define  (first-agenda-item  agenda) 

Get  ((q  (segment-queue  (^-segment  agenda)))) 

(if  (empty-queue?  q) 

(sequence  (set-segments!  agenda 

(rest-segments  agenda)) 
(first-agenda-item  agenda)) 

(front  q)))) 

(define  (make-agenda) 

(list  '^agenda*  (make-time-segment  0  (make-queue)))) 
(define  the-agenda  (make-agenda)) 

;;  Necessary  Precursors 


(define  (call-each  proceduies) 

(if  (nuU?  procedures) 
done 
(sequence 
((car  imiceduies)) 

(call-each  (cdr  procedures))))) 

(define  Gogical-not  s) 

(cond  ((*  s  0)  1) 

((=sl)0) 

(else  (error  "Invalid  signal"  s)))) 


(define  Oogical-and  si  s2) 

(cond  ((and  (=  si  0)  (=  s2  0))  0) 

((and  (=  si  0)  (=  s2  1))  0) 

((and(=sl  l)(=s2  0))0) 

((and(=sl  l)(=s2  1))  1) 

(else  (error  "Invalid  signals"  si  s2)))) 

(define  Oogical-orsl  s2) 

(cond  ((and  (=  si  0)  (=  s2  0))  0) 

((and  (=  si  0)  (=  s2  1))  1) 

((and(=sl  l)(=s2  0))  1) 

((and(=sl  l)(=s2  1))  1) 

(else  (error  "Invalid  sign^s"  si  s2)))) 

;;  Objects 


(define  (make-wire) 

(let  ((signal-value  0)  (action-procedures '())) 

(define  (set-my-signal!  new-value) 

(if  (not  (=  signal-value  new-value)) 

(sequence  (set!  signal-value  new-value) 

(caU-each  action-procedures)) 

’done)) 

(define  (accept-acdon-procedure  ptoc) 

(set!  action-ptocedures  (cons  proc  action-procedures)) 
(ptoc)) 

(define  (dispatch  m) 

(cond  ((eq?  m  'get-signal)  signal-value) 

((eq?  m  'set-signal!)  set-my-signal!) 

((eq?  m  'add-acdon!)  accept-acdon-procedure) 

((eq?  m  'display-acdon-procedures)  acdon-prcx»iures) 
(else  (error  "Unknown  operadon  ~  WIRE"  m)))) 

dispatch)) 

(define  (get-signal  wire) 

(wire  'get-signal)) 

(define  (set-signal!  wire  new-value) 

((wire  'set-signal!)  new-value)) 

(define  (add-acdon!  wire  action-procedure) 

((wire  'add-action!)  acdon-proi^ure)) 

(define  (display-action-procedures  wire) 

(wire  'display-action-procedures)) 


102 


(define  (inverter  input  output) 

(define  (invert-input) 

(let  ((new-value  (logjcal-not  (get-signal  input)))) 

(after-delay  inverter-delay 
(lambda  () 

(set-signal!  output  new-value))))) 

(add-action!  input  invert-input)) 

(define  (and-gate  al  a2  ou^ut) 

(define  (and-actitxi-procedure) 

Get  ((new-value  Gogical-and  (get-signal  al)  (get-signal  a2)))) 
(af^-delay  and-gate-delay 
Gambda  0 

(set-signal!  output  new-value))))) 

(add-acdon!  al  and-acdon-procedure) 

(add-acdon!  al  and-acdon-procedure)) 

(define  (or-gate  ol  o2  output) 

(define  (or-acdon-procedure) 

(let  ((new-value  (logical-or  (get-signal  ol)  (get-signal  o2)))) 
(af^-delay  or-gate-delay 
Gambda  0 

(set-signal!  output  new-value))))) 

(add-acdon!  ol  or-acdon-procedure) 

(add-acdon!  o2  or-acdon-procedure)) 

(define  (half-adder  a  b  s  c) 

Get  ((d  (make-wire))  (e  (make-wire))) 

(or-gate  a  b  d) 

(and-gate  a  b  c) 

(inverter  c  e) 

(and-gate  d  e  s))) 

;;  Sample  Simuladon 


(define  (after-delay  del  acdon) 

(add-to-agenda!  (+  del  (current-time  the-agenda))  acdon  the-agenda)) 

(define  (propagate) 

(if  (empty-agenda?  the-agenda) 

'done 

Get  ((first-item  (first-agenda-item  the-agenda))) 

(first-item) 

(remove-fhst-agenda-item!  die-agenda) 

(propagate)))) 


(define  (probe  name  wire) 

(add-action!  wire 
(lambda  () 

(piinc  name) 

(princ"  Attime  =  ") 

(princ  (current-time  the-agenda)) 
(prmc "  New  value  = ") 

(princ  (get-signal  wire)) 
(newline)))) 

(define  inverter-delay  2) 

(define  and-gate-delay  3) 

(define  ar-gatc-delay  5) 

(define  input- 1  (make- wire)) 

(define  input-2  (make-wire)) 

(define  output  (make-wire)) 

(define  cany  (make-wire)) 

(probe  'input- 1  input- 1) 

(probe  'output  output) 

(probe  'cany  carry) 

(half-adder  input- 1  input-2  output  cany) 
(set-signal!  input-1  1) 
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APPENDIX  D 


The  code  for  the  Excel  aircrew  scheduler  is  attached.  User-specified  names  and 
data  structures  are  not  included,  as  the  code  is  intended  only  to  show  the  visual 
programming  methodology  mote  clearly.  Code  modularity,  control  structures  used,  and 
placement  is  apparent,  but  the  code  has  been  expanded  to  stow  detail.  Ordinarily,  columns 
are  much  more  narrow,  and  lines  of  code  that  are  wider  than  the  column  not  entirely 
visible.  This  is  shown  in  the  second  copy  of  the  same  code. 
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mm 

mm 

mm\ 

Vert 

Item 

Item 

Pos 

Hqht 

Wdth 

Init/Resul 


Static  Text  5 


6 


16 


tatjc  Text  5 


Name: 


tatic  Tex 


Static  Text  1 5 


tatic  Text 


6 


Ok  Button  1 1 


Cancel  Butto 


No.  comolet 


No.  completed: 


DACBT 


No.  comoleted: 


lEnter 


Cancel 
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From: 
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APPENDIX  E 


The  following  code  is  an  example  of  the  functicMial  programming  used  by  most 
spreadsheet  programmers.  The  program  uses  four  inputs  to  generate  and  print  out  Ha^a  on 
a  form  used  to  justify  rental  cars  for  government  travel.  All  parameters  are  visible  to  the 
user  and  may  be  edited  directly.  The  only  noti-automared  requirement  is  a  data>of-travel 
text  change  on  the  form.  Formulas  used  to  do  the  calculations  are  shown. 
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RADCyCX)  Capt  Doug  Dyer  8-May-90 


1.  No  adequate  govenunent  or  public  transportadon  exists  between  points  of  arrival, 
TD  Y  location(s)  and  lodging/m^  facilities. 

2.  Date  of  travel  13-14  Jun  90  Number  of  travelers  3 

3.  COMMERCIAL  TRANSPORTATION  (Circle  appropriate  mode) 

Limo/taxi  -  airport  to  motel:  $4.(X)  X  Nr  of  Travelers  3  =  $12.00 

Taxi/ •  motel  to  TDY  station  $16.00  XNrofR/T  6  =  $96.00 

Limo/taxi  •  motel  to  airport:  $4.00  X  Nr  of  Travelers  3  =  $12.00 

Total  Cost:  $120.00 

4.  RENTAL  CAR: 

$33.00  per  day  X  2  day  $66.00 

$1.00  pergaLofgasX  1  gallon  (20  miles)  $1.00 

Total  Cost:  $67.00 

5.  SAVINGS  TO  THE  GOVERNMENT:  $53.00 

6.  Rental  Vehicle  arrangements  completed  by  SATO  on  8-May-90 


x2973 


DOUGLAS  E.  DYER,  Capt,  USAF 


|ganAj..n7j.i 


Rental  Car  Justification;  TO  USE,  CHANGE 


F  TRAVEL,  SATO  RESERVATION  TO  LEFT,  THEN  PRINT 


FIRST  PAGEON  FORM  1820,  CHECK  RENTAL  CAR  AND  SIGN 


Miles 


The  following  data  are  required  for  calculation 


Distance  from  Airport  to  Motel  Loc 


Hotel  to  TDY  Locati 


Number  of  Days  at  TDY  Location:  I  2 1  Days 


3 


I  Change  each  time 


Change  each  time 


e  of  airport  carrier  (limo/i 


Solo  Travel  Cost  to  Motel  nom  Ai 


olo  Travel  Cost  to  Airport  hrom  M 


Total  Travel  C^t  to  and 


bst/mile  of  local  carrier  (taxi): 


Number  of  trips  between  hotel  and 


Travel  to  and  from  Hotel: 


.00 


24.00 


II 


Change  Occasionally 


Change  Occasionally 


t  of  gas  (per  gallon): 


es  of  travel  required; 


Estunated  Fuel  Costs:  (20mpg) 


Total  Cost  of  Ren 


ge  Frequently 


ange  Occasionally 


t  savmgs  to  the  Government 


NOTE:  MUST  EX 
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Automated  Ren 


FIRST  PAGE  ON  FORM 


|Kfll£ _ 


e  following  data  are 


Airponto 


^1 


lli^ 

iiij 

iUCS 

■»ireg 

ly^ 
I£IB: 


umber  of  Days  at  TDY 


umber  of  travelers 


ni 


mmon  Carrier  Costs — 


t/mile  of  airport  earn 


olo  Travel  Cost  to  Motel 


olo  Travel  Cost  to  Aiipoi 


Total  Travel  Cost  to  and 


ost/imle  of  local  carrier  ( 


Number  of  trips  between 


ravel  to  and  from  Hotel: 


lU 

liyi 


St  of  gas  (per  gallon): 


stimated  miles  of  travel 


Jl 


j  i:gTTn7rn?nrtfTn  i 

j[j2  2Iis2  E 


IE£II 
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APPENDIX  F 


The  following  code  is  a  solution  to  the  8-puzzle  describe  in  Nilsson's  book.  Note 
that  the  spreadsheet  representation  closely  matches  Nilsson's  Figure  1.2.  Concrete  data 
structures  are  much  easier  to  work  with  than  invisible  ones.  Dunng  execution,  the  program 
explores  the  possible  moves  and  picks  the  one  which  reduces  the  error  most  (hill  climbing). 


3 


Eieht  Puzzle: 


2 

8 

1 

6 

Out-of-place  matrix: 


-1 


-1 


0 


The  value  of  the  Hill  Climbing  Function  is: 


Hill  Climbing  Function  is  a  summation  of  the  out-of-place  matrix. 


or  "minus"  the  number  of  tiles  out  of  place 


E 


Desired  puzzle  confi 


1 


8 


don  at  completion: 


2  3 


APPENDIX  G 


The  following  code  is  used  to  rec^  long  distance  telephone  data  using  a  visual 
input  and  as  much  default  information  as  possible.  The  program  uses  pull-down  menus  to 
start  and  end  a  call  and  paste  the  called  patty’s  data  into  a  da^base.  If  the  parQr  has  not 
been  called  before,  the  ^ta  is  stored  in  a  table  which  may  be  edited  or  sor^  At  the  end  of 
the  month,  the  user  sends  the  data  file  produced  by  the  program  across  a  netwoik  to  an 
analysis  center.  The  analysis  center  has  anodier  program  which  consolidates  data  into  (me 
file  and  af^lies  the  analysis  fiincticmality  inherent  in  Excel  to  flexibly  analyze  the  data  and 
discover  errors. 
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turn 


Info:  •••••••••••< 


The  dau  to  the  left  is  im 


You  mnr  maniull; 


Distance  nucioe 


re  callina  is  nonmaUy  stored  in  the  list  below. 


You  may  edit  that  list  and  sort  it  usi 


When  reouested.  make  a  datt  ftle  and  TOPS  this  fQe  to 


Only  a  duplicaie  of  the  dam  file  will 


To  be  safe,  don't  delete  nooida  anal  they  are  at  leaat  tiro  mondia  dd. 


Lastuiaento 


412-268*3842 


Dr  Bin  Wolf 


CITY 

STATE 

TELEPHONE  NO. 

nttsburxh 

PA 

412-268-3842 

C5SR53BH 

VA 

703-695-1766 

VA 

703-276-3330 

MA 

617-229-6563 

Lubbock 

TX 

806-742-3904 

Unknoim 

VA 

703-522-6221 

VA 

804-451-0000 

iScoltAFB  1 

IL 

618-632-2424 

CA 

213-3934)404 

CA 

619-224-3460 

USE  DATA  TO  LEFT 


Dr  Bill  Wolf 


MaUe 


Dr  John  Smith 


Jean  La  Greene 


Jack  Whits 


Dr.BOl'nicfcer 


Dr.  Jdae  Cuervo 


COMPANY  CALLED 


MCU 


SAKCDRlPAyiNFO 


SAK 


Maniot  Bw  'in 


Texas  Institute  of  Tecfanol 


Ccmftxtlnn 


Miter  M 


ISAND 
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start  call 


-FORMULA(”Yes",lprocessinQ  fla 


-SELECT(!A2:K2 


■OEFINE.NAMErcurrent  row” 


.SELECT(,-rc[1 


>DEFINE.NAMErstart  tlme*.ACTIVE.CELL 


.SELECT(.-rcL8 


DEFINE.NAME(*duration*>VCTIVE.CE 


end  call 


«SELECT(”duration  calc 


-CALCULATE.NOW 


-COPYi 


IOCSi!i3n 


>DEFINE.NAMErreason 


-CXDPY 


«SELECT{’current  row 


-PASTE.SPECIAL(3,1 


lemnsii 


■PASTE.SPECIAU3.1 


FORMAT>IUMBERrh.*mmss 


FORMULArNo", Iprocessinq  fla 


-RETURN 


-RETURN 


on  open 


.AOO.MENU(5 


-RETURN 


Long  Distance 


Begin  Call 


Who's  Called?... 


Comment.. 


End  Call 


Cancel  Call 


Make  data  file 


Ion  close 


-OELET&MENUf1.9 


-a< 


-RETURN 


'Log  Macros’istart  call 


Macros'loaste  who 


'Log  Macros’lcomment 


Macros'lend  call 


'Log  Macros'lcan  it 


'Log  Macros'lmake  data  file 


le 


can  it 


IF(!processing_flag-''Yes'',GOTO{A39 


-ALERTCNo  call  in  process", 3 


-RETU 


-SELECT(iA2d<2 


-EOIT.DELETE 


FORMULArNoM 


-RETU 
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aste  who 


DIALCX3.BOX($E$2:$K$1 


IF(NOT{C2).RETJURN 


IF(K15>i1,GOTO(process  data 


«K15 


SELECT(”datahome 


-  down(C5 


SELECTrrc:rcr4 


-COPY 


-SELECTCcI 


-PASTE 


-RETURN 


rocess  data 


IE 


FORMULA(K12 


-SELECT(I018 


-FORMU 


-SELECT(tP18 


-FORMULA(K6 


-SELECT(iQ18 


-FORMULA(K8 


-IF(Kl6,lnsert  data 


-SELECT(IM18 


-QOTO(C9 


20 


21  make  data  file 


22  -SELECTfOatabase 


23  -COPY 


24  -NEWd 


2S  -PASTE 


2  6  -OEFINENAMErdala^ 


27  -SAVE.AS(I$C$2&"  Long  Distance  OataM 


28 


29  -RETU 


30 


insert  data 


-SELECTCdatahome” 


-SELECT(-rf11c:rrilcf4 


1C 
1C 


-SELECT(IM18 


SELECT(-rc:rcf4 


-COPYi 


-SELECTrdatahome 


-PASTE 


-RETURN 


comment 


SELECT(”reason 


1C 


-RETU 


down 


-ARGUMENT 


-SELECTf.-rfI 


1C 


SET.VALUE(C45.moves-1 


-SELECTf.-rfI 


-C45-1 


IF(C45<1  .RETURNO.QOTO(C44 


ic 


-ARGUMENT 


SELECT 


IFdSNAfmovesl.RETURN 


SET.VALUE{D86.move8‘1 


SELECT 


-D86-1 


iF(D86<1  .RETURNO.GOTO(D85 
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ROME  LABORATORY 


Rome  Lfmaratary  plans  and  executes  an  interdisciplinary  program  in  re¬ 
search,  development,  test,  and  technology  transition  in  support  of  Air 
Force  Command,  Control,  Communications  and  bitelligence  (C^D  activities 
for  all  Air  Force  platforms.  It  also  executes  selected  acquisition  programs 
in  several  areas  of  expertise.  Technical  and  angtneering  support  within 
creas  of  competence  is  provided  to  BSD  Program  Offices  (POs)  and  other 
ESD  elements  to  perform  effective  acquidtian  of  C^I  systems.  St  addition, 
Rome  Laboratory s  technology  supports  other  AFSC  Product  Divisions,  the 
Air  Force  user  community,  and  other  DOD  and  nonrDOD  agencies,  Rome 
Laboratory  maintains  technical  competence  and  research  programs  in  areas 
including,  but  not  limited  to,  communications,  command  and  control,  battle 
management,  intelligence  information  i^xrcesslng,  computational  sciences 
and  software  producibUity,  wide  area  surveillance/sensors,  signal  proces¬ 
sing,  solid  state  sciences,  photonics,  electromagnetic  technology,  super¬ 
conductivity,  and  electronic  reliabOity/maintatnabUity  and  testability. 


